httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Nasty chunking bug (in MSIE?) when using ap_rwrite()/ap_rflush()
Date Mon, 16 Jul 2001 18:58:22 GMT

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). 
> handler is done
>  > at this point and returns control to Apache.  The next thing Apache 
> 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 
> 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
>  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'.

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

View raw message