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
