On 25/01/2013 10:29 a.m., Michael Graham wrote:
Hi all,
We recently upgraded to squid 3.2.5 and found we were unable to get to
the site http://www.alevel-english.co.uk, after a little digging
around it seems like the site doesn't like being sent a content length
with a GET.
I realise that this is perfectly valid (although from my understanding
optional), but I have the attached patch that stops squid from sending
this header when it is doing a GET.
I'd love someone to give it a quick review and comment on what they
think.
Thanks,
In future patches should be sent to squid-dev mailing list with
"[PATCH]" prefix for review.
There are two issues with this change.
* GET _can_ have Content-Length and entities. This was discussed at
some length in the IETF HTTPbis Working Group when reviewing RFC 2616.
The conclusion was that the meaning of GET without a Content-Length or
Transfer-Encoding header is different to the meaning of a GET with
either one.
The updated specification cops out though:
"
A payload within a GET request message has no defined semantics;
sending a payload body on a GET request might cause some existing
implementations to reject the request.
"
Either way stripping these headers from GET requests automatically is
likely to cause more trouble than leaving it on does. Squid provides a
config directive which switches between rejecting and handling normally.
http://www.squid-cache.org/Doc/config/request_entities/ - notice how
the default is OFF, so you have to explicitly have enabled these
requests for them to reach the upstream server like you said was happening.
Are you seeing Squid acting as a relay for the header?
or generating these headers itself on the upstream request?
- please provide level 11,2 debug header trace for the client inbound
request and Squid outbound request messages to verify that.
As for the code itself:
* setting the content length is not a feature isolated to HTTP
requests. Replies also need to set it. The Squid code is just doing a
lot of abuse in the Reply code by not using the accessor properly.
- Instead of moving it should be made a virtual method with a
speial-case version in HttpRequest.
- It should be using "clientIsContentLengthValid(request)" instead of
a test of the method.
(yes, the test function itself needs cleaning up better as well,
there are other criteria beyond GET involved.)
Amos
