[OT] False timeout error after URL retrieval

[J. Landman Gay]

On 5/5/2015 2:39 PM, Trevor DeVore wrote:
> On Tue, May 5, 2015 at 3:25 PM, J. Landman Gay <jacque at hyperactivesw.com>
> wrote:
>
>> On 5/5/2015 1:21 PM, Trevor DeVore wrote:
>>
>>> Jacque,
>>>
>>> It sounds to me that the server is sending back an incorrect content
>>> length
>>> header for the data that is being sent to LiveCode. LiveCode maybe waiting
>>> for more data that is never going to arrive. Try comparing the actual
>>> length of the data to the content length value in the header and see if
>>> they match.
>>>
>>>
>> What a good idea. I looked at the headers and there is no content-length
>> included at all. Do we need one?
>
>
> I would think so. You would need one to determine the percentage of the
> file you've downloaded. Looking at the RFC doc for message length if you
> don't have the content-length then in your case you would need to be using
> a different transfer encoding or the server has to close the connection to
> terminate the file transfer. Can you show an example header?
>
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4
>

Here's a sample of the headers being sent:

HTTP/1.1 200 OK
Date: Tue, 05 May 2015 19:54:40 GMT
Server: Apache/2.4.4 (Unix) OpenSSL/1.0.1 Phusion_Passenger/4.0.59
Content-Disposition: attachment
Content-Transfer-Encoding: binary
Cache-Control: private
X-UA-Compatible: IE=Edge,chrome=1
X-Request-Id: ada798669ddb792678c81c63e496097e
X-Runtime: 1.030435
X-Rack-Cache: miss
X-Powered-By: Phusion Passenger 4.0.59
ETag: "fd33e2e8ad3cb1bdd3ea8f5633fcf5c7"
Status: 200 OK
Transfer-Encoding: chunked
Content-Type: application/octet-stream


Some of this means little to me. But I am pretty sure adding a content 
length header wouldn't be too hard.

-- 
Jacqueline Landman Gay         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com