On 29/04/11 01:38, Supratik Goswami wrote:
@Amos
Thanks for the information.
There is one confusion still in my mind. How reply_body_max_size is
able detect it ?
In the Squid documentation it says:
"This size is checked twice. First when we get the reply headers,
Note at this point the TCP connection is wide open, the request is
already sent, the reply has been created and has started arriving back.
Far to late to decide which IP to use when opening the TCP connection.
we check the content-length value. If the content length value exists
and is larger than the allowed size, the request is denied and the
user receives an error message that says "the request or reply
is too large." If there is no content-length, and the reply
size exceeds this limit, the client's connection is just closed
Note at this point all of the above has happened PLUS the reply headers
and large portion of the reply body have been received AND relayed on to
the client already.
Far too late to send anything else back to the client. The *only*
choice is to abort with a TCP RST (TCP closure implying an error has
happened).
and they will receive a partial reply."
So, I think if something similar to reply_body_max_size or any
workaround is present which uses reply_body_max_size directive
then the issue could be easily resolved.
If the proxy was psychic perhapse. A serial sequence of events being the
key problem.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.12
Beta testers wanted for 3.2.0.7 and 3.1.12.1
