Ian Holsman wrote:
[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
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);
