Re: [squid-users] Content-length 0 on GET [patch?]

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
Received on Sat Jan 26 2013 - 04:59:42 MST