Hi list,
thanks for the replies. Looks like squid in case Content-Length
response header is missing, does it's limitation in a "hard" way (snip
from src/client_side.c):
} else if (clientReplyBodyTooLarge(http, http->out.offset - 4096)) {
/* 4096 is a margin for the HTTP headers included in out.offset */
comm_close(fd);
} else {
However this seems to be the only way in case we want to avoid content
buffering. mod_security also relies on Content-Length an if is not
present, output buffering (and I suppose the limitation as well) stops
(snip from apache2/apache2_io.c:output_filter):
case 0 :
/* We do not want to observe this response body
* but we need to remain attached to observe
* when it is completed so that we can run
* the RESPONSE_BODY phase.
*/
msr->of_skipping = 1;
msr->resbody_status = RESBODY_STATUS_NOT_READ;
break;
On 2/13/07, Nick Kew <[EMAIL PROTECTED]> wrote:
On Mon, 12 Feb 2007 23:35:24 +0100
Henrik Nordstrom <[EMAIL PROTECTED]> wrote:
> mån 2007-02-12 klockan 21:55 +0000 skrev Nick Kew:
>
> > Because the chunking filter is equipped to discard the chunk that
> > takes it over the limit, and substitute end-of-chunking.
> > If we do that in a new filter, we have to reinvent that wheel.
>
> Not sure substitue "end-of-chunking" is a reasonable thing here. It's
> an abort condition, not an EOF condition. Imho you'd better abort the
> flow, that way telling the client that the request failed instead of
> silently truncating the response.
How would you abort it other than by truncating it?
Don't forget, the headers are long gone.
If you don't send an end-marker, the client will
sit there waiting for more.
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/
--
Dziugas
