On 01/07/2008 12:07 AM, Nick Kew wrote:
> On Sat, 5 Jan 2008 00:07:42 +0000
> Nick Kew <[EMAIL PROTECTED]> wrote:
>
> A quick heads-up:
>
>> Regression: fails to proxy massively chunked responses.
>
> r609394 fixes this, but introduces (or unmasks) new issues
> with chunked data edge-cases. Specifically, two testcases
> in which the termination of the chunked data involves
> extra zeros (65 in total):
>
> [valid chunk]
> 0000000000000000000000000000000000000000000\r\n
> \r\n
>
> Silly, but technically we should accept it.
>
> 1. With that in the Request, httpd rejects it with 413.
> Seems fair to me.
>
> 2. With that in the Response, httpd breaks more seriously:
> it fails to forward *any* termination, and the client is
> left in limbo expecting more data. This one we need to fix.
>
> The response trace is:
>
> HTTP/1.1 200 OK\r\n
> Transfer-Encoding: chunked\r\n
> Date: Sun, 06 Jan 2008 22:47:28 GMT\r\n
> Connection: close\r\n
> \r\n
> 64\r\n
> [data]\r\n
> 00000000000000000000000000000000000000000000000000000000000000000\r\n
> \r\n
>
> which the proxy turns into:
>
> HTTP/1.1 200 OK\r\n
> Date: Sun, 06 Jan 2008 22:47:28 GMT\r\n
> Via: 1.1 grimnir.webthing.com\r\n
> Connection: close\r\n
> Transfer-Encoding: chunked\r\n
> \r\n
> 64\r\n
> [data]\r\n
> **** nothing more! ****
No fix is needed here. If you do a closer inspection of the network traffic you
will notice that
after [data]\r\n is sent the server closes the TCP connection. This is the
expected behaviour
and does not cause the client to wait for anything. This is the way we go in
this case:
(line numbers of trunk)
http_filters.c:407 get_chunk_line returns APR_ENOSPC
http_filters.c:436 We leave ap_http_filter with return code APR_ENOSPC
mod_proxy_http.c:1617 ap_get_brigade returns APR_ENOSPC
mod_proxy_http.c:1645 we get here log a message, ensure that the connection to
the backend
will get closed upon return to the pool and that the
connection to the
client is terminated immediately.
See http://svn.apache.org/viewvc?view=rev&revision=357461 for more details. It
is intended
that we do NOT sent the last-chunk marker in this case to indicate the client
that something
broke horribly.
Regards
Rüdiger
