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

On 1/25/2013 11:59 PM, Amos Jeffries wrote:
> 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.

In which case I think I need to explain a little more about what is
going on :)

We have two squid servers and an icap server. The traffic goes squid-1
-> icap server -> squid-1 -> squid-2.

Squid-1 gets:

GET http://www.alevel-english.co.uk/ HTTP/1.1
Host: www.alevel-english.co.uk
Proxy-Connection: keep-alive
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.17
(KHTML, like Gecko) Chrome/24.0.1312.56 Safari/537.17
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: JSESSIONID=49C99A77DF1CA1963718AE68DAA79494;
ASPSESSIONIDQACASQTQ=JBAFBAFDICFKCOJOJPOELOMD;
__utma=263889116.1108959357.1359039306.1359129876.1359388636.6;
__utmb=263889116.1.10.1359388636; __utmc=263889116; __utmz=263889116.1359
039306.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)

So no transfer-encoding, it then sends this to icap:

REQMOD icap://127.0.0.1:1344/ ICAP/1.0
Host: 127.0.0.1:1344
Date: Mon, 28 Jan 2013 16:07:30 GMT
Encapsulated: req-hdr=0, null-body=714
Preview: 0
Allow: 204
X-Client-IP: 192.168.68.51

GET http://www.alevel-english.co.uk/ HTTP/1.1
Host: www.alevel-english.co.uk
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.17
(KHTML, like Gecko) Chrome/24.0.1312.56 Safari/537.17
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: JSESSIONID=49C99A77DF1CA1963718AE68DAA79494;
ASPSESSIONIDQACASQTQ=JBAFBAFDICFKCOJOJPOELOMD;
__utma=263889116.1108959357.1359039306.1359129876.1359388636.6;
__utmb=263889116.1.10.1359388636; __utmc=263889116; __utmz=263889116.1359
039306.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)

Which then gets the following back from ICAP:

ICAP/1.0 200 OK
Server: Traffic Spicer 2.2.2
ISTag: "Bloxx/v2.2.2/c5edeb8/vBLOXX"
Encapsulated: req-hdr=0, req-body=789

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
Cache-Control: max-age=0
Cookie: JSESSIONID=49C99A77DF1CA1963718AE68DAA79494;
ASPSESSIONIDQACASQTQ=JBAFBAFDICFKCOJOJPOELOMD;
__utma=263889116.1108959357.1359039306.1359129876.1359388636.6;
__utmb=263889116.1.10.1359388636; __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.56 Safari/537.17
X-Bloxx-Result: [201, 203, 250, 251, 252, 254, 255, 256, 401, 2100, 2106]

0

Nothing really changes other than the addition of our customer header.
At this point squid then sends this to the next squid, and I think this
is where the issue is:

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: JSESSIONID=49C99A77DF1CA1963718AE68DAA79494;
ASPSESSIONIDQACASQTQ=JBAFBAFDICFKCOJOJPOELOMD;
__utma=263889116.1108959357.1359039306.1359129876.1359388636.6;
__utmb=263889116.1.10.1359388636; __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.56 Safari/537.17
X-Bloxx-Result: [201, 203, 250, 251, 252, 254, 255, 256, 401, 2100, 2106]
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

Squid has added the transfer-encoding but we don't have a body... we at
least that is my understanding of the icap protocol at this point.

This then becomes:

GET / 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: JSESSIONID=49C99A77DF1CA1963718AE68DAA79494;
ASPSESSIONIDQACASQTQ=JBAFBAFDICFKCOJOJPOELOMD;
__utma=263889116.1108959357.1359039306.1359129876.1359388636.6;
__utmb=263889116.1.10.1359388636; __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.56 Safari/537.17
X-Bloxx-Result: [201, 203, 250, 251, 252, 254, 255, 256, 401, 2100, 2106]
Content-Length: 0
Via: 1.1 pluto-icap (squid/3.2.5), 1.1 pluto-cache (squid/3.2.5)
X-Forwarded-For: 192.168.68.51, 127.0.0.1
Cache-Control: max-age=0
Connection: keep-alive

And the upstream server isn't very happy and returns at 405 response.

So given that the reqmod code seems to have added a transfer-encoding
header without a body, perhaps this is the place I should be looking?

Cheers,

-- 
Michael Graham