Re: Nasty chunking bug (in MSIE?) when using ap_rwrite()/ap_rflush()

[Ian Holsman]

[EMAIL PROTECTED] 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          [EMAIL PROTECTED]
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