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
