httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Holsman <i...@cnet.com>
Subject Re: Nasty chunking bug (in MSIE?) when using ap_rwrite()/ap_rflush()
Date Tue, 17 Jul 2001 01:56:33 GMT
TOKILEY@aol.com wrote:

>In a message dated 01-07-16 18:16:37 EDT, Ian Holsman wrote...
>
>>On 25 Jun 2001 12:13:51 -0400, Bill Stoddard wrote:
>> > I have a module that calls ap_rwrite() followed by ap_rflush().  Content 
>>length is not
>> > provided so Apache 2.0 chunks the response.
>> > 
>> > Here is what happens...
>> > I call ap_rwrite() to write a x75 len byte stream.  All the correct 
>>headers are built, and
>> > the content is buffered by the OLD_WRITE filter. Then I call ap_rflush() 
>>which causes the
>> > headers to be sent on the wire along with the first chunk (x75 length). 
>>
>My 
>
>>handler is done
>> > at this point and returns control to Apache.  The next thing Apache 
>>
>sends 
>
>>on the wire is
>> > the 0 byte chunk header to indicate that the response is done.
>> > 
>> > The problem: IE chokes when it receives just the 0 byte chunk header in 
>>
>a 
>
>>packet.
>> > 
>> > Thoughts?
>> > 
>> > Bill
>> 
>> 
>> hi Bill, 
>> I was wondering if you got anywhere with this
>> I'm seeing this with mod_proxy at the moment.
>> 
>> my inital thought was to put some logic in the chunking filter
>> just not to send the 0 byte chunk out.. can you see anything barfing
>> on this?
>> 
>> what do you think?
>> 
>> --
>> Ian Holsman          IanH@cnet.com
>> Performance Measurement & Analysis
>> CNET Networks   -   (415) 364-8608
>>
>
>You have to send the 0 byte chunk... but that's not all 
>there is to it. The 'Entity headers' and then the final
>'blank line' (CR/LF) is what actually ENDS the 
>chunked transfer.
>
>You have to 'hang tough' on the client side on a 'Keep-Alive'
>and only use the final blank CR/LF as an EOD signal. You
>can't bail when the '0' chunk length shows up or you could
>end up leaving the Entity headers + final blank CR/LF in
>the input buffer and think these chars are the start of 
>the next response when you get back to reading your
>input buffers on the NIC on next Keep-Alive.
>
>Whoever/whatever is 'adding' the '0' byte must also be
>adding A) The CR/LF that follows the 0 byte hex string
>B) All of the Entity Headers + CR/LF ending each one
>C) The final 'blank' CR/LF that ends the chunking.
>
>If any of the above is missing maybe that is why
>MSIE is 'choking'.
>

MSIE is choking due to a '0' byte happening in the middle of the 
response being sent back.

I think this is due to the proxy code sending a EOS bucket after the 
subrequest. (it doesn't happen with non-proxied
requests), hopefully it will be easy to find.

>
>
>I would find it hard to belive that a modern browser would
>screw up a chunking byte length appearing all by itself
>at the top of a new packet ( Even though that's highly
>unusual... usually it's right at the end of the data in
>the same final data packet ).
>
>Kevin Kiley
>

..Ian


Mime
View raw message