[RFC] HTTP problems caused by broken ICAP servers

Alex and co., I'd like your feedback on this please...

The issue outlined very clearly in this squid-users mail:
http://www.squid-cache.org/mail-archive/squid-users/201301/0358.html
is that ICAP server was broken and producing a stupid response.

> On 1/28/2013 11:24 AM, Michael Graham wrote:
>> 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
>
> This is the problem here. This should be null-body=789. If I fix the
> icap response so that we say null-body then the first squid doesn't
> add the Transfer-Encoding header, which the second squid then converts
> into a Content-Length: 0 header.

Now that the problem is identified, I can recall it being debugged by
Alex multiple times in the past as well for other users.

Can we add some better protocol idiocy detection on the ICAP responses
please?

I know Squid is faithfully replicating what ICAP tol it to produce. But
we need something to flag when ICAP is telling Squid to produce a risky
HTTP syntax combination. Or something the Squid admin has configured (or
defaulted) to not be possible.

Thanks
Amos
Received on Tue Jan 29 2013 - 10:50:49 MST