Re: Question about proxies forwarding HTTP/1.0 responses

On Thu, 27 May 2004, Jamie Lokier wrote:

> Alex Rousskov wrote:
> > Proxies that claim HTTP/1.1 support usually send HTTP/1.1 messages. A
> > few proxies have an option to configure the protocol version in the
> > messages they sent.
>
> ... you have given me confidence that it is fine to omit all the
> user-agent checks which affect hop-by-hop if there's a Via header.

Please note that I said "usually send". All products I know have
agent-specific workarounds. I do not know whether it is OK to do no
agent-specific workarounds if there is a Via header. I suspect it may
NOT be OK in some cases since Via header does not necessarily indicate
that the message will be "fixed" by another proxy on the way to the
broken agent.

Many things in the path may add Via headers, some of which are not
even HTTP proxies. Consider ICAP servers, for example (RFC 3507).

> Yes, but because of some broken HTTP implementations there are
> workarounds deployed.  I wondered if a proxy would forward a
> HTTP/1.0 response and label it as if the sender was HTTP/1.0 as part
> of the workarounds which kept the net working in 1997 or so.

IMHO, the Internet still works on workarounds, to a large extent. This
sad situation is not going to change until we aim higher than just
"running code". I am not sure we ever will.

> Do you know of any practical compatibility reason why Squid must
> report itself as HTTP/1.0 even if it supported all HTTP/1.1 proxy
> requirements?  Or is it simply that it doesn't implement the
> requirements yet?

Last time I checked, Squid did not support all RFC 2616 MUSTs and so
Squid developers [correctly] decided not to use HTTP/1.1 version in
the headers. Here is a probably outdated HTTP/1.1 checklist for Squid:
	http://devel.squid-cache.org/squidhttp1.1.htm

Note that announcing HTTP/1.1 support buys you little. For good or
bad, you can do persistent connections, ranges, Vary, and other key
HTTP/1.1 features while announcing HTTP/1.0 compliance only.

Alex.

Received on Thursday, 27 May 2004 11:09:44 UTC