Re: Question about proxies forwarding HTTP/1.0 responses

Alex Rousskov wrote:
> > ... 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.

That's true, but the workarounds I wish to omit if Via is present are
specifically only the hop-by-hop ones, equivalent to Apache's
downgrade-1.0 and force-response-1.0.

The nokeepalive workaround is already only done by Apache if Via isn't
present.  Although it isn't documented, Squid also has a workaround
which disables keep-alives with Netscape 3.x -- one which Apache
curiously doesn't have in its default configuration, although Apache's
documentation mentions it.  Squid's workaround is also only done if
Via isn't present.

So that's fine.

force-response-1.0 means the server announces HTTP/1.0 instead of
HTTP/1.1.  If it's true that real HTTP/1.1 proxies do _not_ pass along
the HTTP version announcment of the response (hence the subject of
this thread), and HTTP/1.0 proxies always announce HTTP/1.0, then
force-response-1.0 would have no effect on the broken clients when the
request is via a proxy.

So that's fine if it's disabled by Via.

downgrade-1.0 is really there to disable chunked responses.  If real
HTTP/1.1 proxies _do_ convert non-chunked responses from the server to
chunked HTTP/1.1 responses to the client, assuming the client
announced HTTP/1.1, then downgrade-1.0 would not be effective in this
case anyway.

That means the only functional place for that workaround is at the
nearest proxy to the client, if the proxy is HTTP/1.1.  It is not
effective at the server if there's a proxy and it converts a
non-chunked response to HTTP/1.1 chunked.

I guess that one depends on the behaviour of real proxies.  So that's
banother question: do real deployed HTTP/1.1 proxies convert
non-chunked responses to chunked?

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

The question is whether those things modify the hop-by-hop
characteristics of the message -- i.e. HTTP version, keep-alive, and
chunkedness.  Hmm.  I'd guess ICAP servers would have to, simply
because deployed origin servers already check Via for determining
whether to apply a nokeepalive rule.

> 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.

Indeed, I was not too impressed at the code in _any_ of the servers
and proxies I looked at for parsing HTTP headers.  They work as long
as their peers send politely formatted messages.  Message headers with
embedded CRs and spaces in the field names and continuations are
interpreted in lots of different ways.

> 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.

Not to mention that there are plenty of server implementations which
are far from RFC 2616 compliant that announce themselves as HTTP/1.1,
so it cannot be taken too seriously.

Does announcing HTTP/1.1 actually buy you anything at all?

-- Jamie

Received on Thursday, 27 May 2004 11:39:37 UTC