On 26/01/2013 5:18 a.m., Michael Graham wrote:
On 1/24/2013 7:48 PM, Amos Jeffries wrote:
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.
It was doing both (our ICAP server adds the header too) but as you can
see squid is doing it even when it doesn't receive the header:
----------
2013/01/25 13:02:29.721 kid1| client_side.cc(2298) parseHttpRequest:
HTTP Client local=127.0.0.1:6045 remote=127.0.0.1:33733 FD 12 flags=1
2013/01/25 13:02:29.721 kid1| client_side.cc(2299) parseHttpRequest:
HTTP Client REQUEST:
---------
GET http://www.alevel-english.co.uk/ HTTP/1.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Cookie: ASPSESSIONIDSADASRSR=CMCPPEKAEGPCNPGPEDAMLJNE;
ASPSESSIONIDQCCATQSR=HIBLNKLAOPEBGFHMNDCIKEFD;
ASPSESSIONIDSACBSRSQ=HOEJPOMABLMELLCOFOPHAHKO;
JSESSIONID=D6044F4A7A5C9E9012EC8A26B7E1198F;
ASPSESSIONIDQAADSRTQ=POLNLAEBBCIEFICNBLHFPB
DJ; __utma=263889116.1108959357.1359039306.1359062156.1359118640.4;
__utmb=263889116.3.10.1359118640; __utmc=263889116;
__utmz=263889116.1359039306.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)
Host: www.alevel-english.co.uk
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.17
(KHTML, like Gecko) Chrome/24.0.1312.52 Safari/537.17
Via: 1.1 pluto-icap (squid/3.2.5)
X-Forwarded-For: 192.168.68.51
Cache-Control: max-age=0
Connection: keep-alive
Transfer-Encoding: chunked
----------
I think we need to look a bit closer at this request.
Transfer-Encoding: chunked followed by a zero-length chunk is equivalent
to Content-Length:0 which is why Squid is emitting that Content-Length.
Valid and Content-Length is more portable than Transfer-Encoding since
it passes over HTTP/1.0 hops.
Transfer-Encoding:chunked without *any* following chunk is an invalid
GET request and should have been rejected unconditionally as an invalid
request.
Are you able to get a tcpdump of the packets and see what is going on in
that GET request "body" area from the client?
This is a keep-alive connection, which means it could be corrupting
the connection, or there could be a genuine 0-length chunk entity there.
Amos
