[OT] More on false timeouts and headers

[J. Landman Gay]

Earlier this month, this happened:

On May 5, 2015 6:17:48 PM CDT, Trevor DeVore <[hidden email]> wrote:

 >On Tuesday, May 5, 2015, Dave Cragg <[hidden email]>
 >wrote:
 >>
 >>
 >> From memory, I think the size of each chunk is sent with each chunk
 >itself
 >> in the message portion of the reply, not in the headers.
 >
 >
 > Ah, that would explain it.
 >
 >libUrl should deal with this. It’s a fairly common transfer method.
 >(Sorry,
 >> Jacque, I know that doesn’t help you.)
 >>
 >
 >Yes, the code is in there to deal with it.

We're still trying to deal with this. As it turns out, Passenger is 
adding the "chunked" encoding method header to the output. We no longer 
get a timeout at least (good.) But when libURL receives the data, it 
passes the entire unaltered string to my script (bad) which includes the 
chunking info bytes at the front of the string. I looked at the recently 
revised libURL script and if the LC engine is earlier than 7.0 it does 
return all the data intact without any changes (if it's 7.0 or higher, 
it does some unicode conversion but nothing else.) We're running this 
app in 6.5.7 so the data is passed to my script exactly as it is received.

My script is looking for the initial bytes that indicate a gz file and 
it can't decompress the string that it's receiving. I could remove those 
initial chunk-indicator bytes before trying to decompress, but shouldn't 
libURL remove those first before sending back the data? Is this 
something I should report? Or is it something my app should just deal with?

Meanwhile, back on the server, we're trying to figure out how to avoid 
Passenger's addition of the "chunking" header. Does anyone know of a 
related header we can include that will make Passenger think we want a 
content-length instead?

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