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 16:11:01 GMT
Ian Holsman wrote:

> 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


this seems to fix the problem...
can someone more familiar with brigades/buckets review it

Index: proxy_http.c
===================================================================
RCS file: /home/cvspublic/httpd-proxy/module-2.0/proxy_http.c,v
retrieving revision 1.79
diff -u -r1.79 proxy_http.c
--- proxy_http.c        2001/07/16 17:54:38     1.79
+++ proxy_http.c        2001/07/17 16:07:32
@@ -782,18 +782,20 @@

        /* read the body, pass it to the output filters */
        while (ap_get_brigade(rp->input_filters, bb, AP_MODE_BLOCKING, 
&readbyte
s) == APR_SUCCESS) {
-           if (APR_BUCKET_IS_EOS(APR_BRIGADE_LAST(bb))) {
+               apr_bucket *b = APR_BRIGADE_LAST(bb);
+           if (APR_BUCKET_IS_EOS(b)) {
+               APR_BUCKET_REMOVE(b);
                e = apr_bucket_flush_create();
                APR_BRIGADE_INSERT_TAIL(bb, e);
                ap_pass_brigade(r->output_filters, bb);


Mime
View raw message