Gavin McCullagh wrote:
Hi,
On Thu, 26 Mar 2009, Amos Jeffries wrote:
A very few. Pressure is on them to fix up when they break so it's no
common fortunately.
Phew. I guess if we needed to I can alter our wpad.dat and policy filter
to dictate direct access to norton updates, though I'd really rather not.
I do see this sort of error in the logs occasionally.
Mar 26 11:17:50 proxy squid[2969]: parseHttpRequest: Invalid HTTP version
Mar 26 11:17:51 proxy squid[2969]: parseHttpRequest: Invalid HTTP version
Mar 26 11:17:54 proxy squid[2969]: parseHttpRequest: Invalid HTTP version
Actually that's from a different proxy server running Debian and
2.6.5-6etch4.
It's probably broken software if it happens low-level, but may be a sign
of DDoS attack against your Squid if it's frequent for a period. There
are a few attack vectors featuring invalid HTTP versions (2.6.5-6etch4
was made by Debian to fix the last 2.6 was vulnerable to).
Part of the HTTP/1.1 spec requires that HTTP/1.0 visitors be accepted
and dealt with properly. So the sites are in violation by using the 1.1
moniker when they can't handle critical parts of the spec. (This is one
of the main reasons Squid still says 1.0).
I see.
Is this only in the transparent situation or is it whenever you go through
squid? Is there any version of squid which supports HTTP/1.1 or works
around this yet?
Squid-2.7 can tell servers it is 1.1, but cannot to the client-side part.
Does it help to tell the server you're using 1.1? Will the server not then
respond using 1.1 features which squid doesn't support?
That side of the transafer is nearly completely 1.1 compliant. And Squid
can indicated what features are possible and what not.
The missing compliance in Squid is mostly related to how it handles
client requests.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE6 or 3.0.STABLE13
Current Beta Squid 3.1.0.6
