Re: #158: Proxy-Connection and Keep-alive

Hi Mark,

On Mon, Dec 05, 2011 at 12:01:16PM +1100, Mark Nottingham wrote:
> 
> On 03/12/2011, at 6:22 PM, Willy Tarreau wrote:
> 
> >  The Proxy-Connection header was completely obsoleted by the Connection
> >  header. Therefore, clients must not emit it and must use the Connection
> >  header instead, even with proxies running an unknown HTTP version.
> > 
> > I'm insisting on this point because it's not necessarily obvious that a
> > "Connection: keep-alive" header must be sent in an HTTP/1.1 request when
> > the proxy's version is unknown or 1.0.
> 
> Willy,
> 
> There are a number of problems with this.
> 
> * Your text effectively requires clients to send Connection: keep-alive under certain conditions. This is a new requirement that will very likely break existing implementations, and one that makes HTTP more complex.

It should not as it is what they're doing *right now*. Look at a
proxy request, you'll see both "Proxy-Connection: keep-alive" and
"Connection: keep-alive".

> * Furthermore, we don't define Keep-Alive, as it's not part of HTTP/1.1 (and therefore out of scope). It was previously abandoned as too problematic. Requiring use of a deprecated mechanism doesn't make sense.

I'm not asking to emit the Keep-alive header, rather just to suggest
clients to continue to emit "Connection: keep-alive" when they suspect
the proxy could be 1.0, as they're doing right now.

> * The primary motivation for doing so is compatibility with NTLM authentication, which is also not part of HTTP, and very clearly breaks HTTP. While we can attempt to improve interoperability for this broken extension, it cannot be at the cost of making HTTP itself more complex.

In fact there are two degrees in these motivations :
  - the first one is to maintain a reasonable performance level, but it
    could be argued that if some browsers are slowed down after an upgrade
    due to loss of persistent connections, it's not dramatic, except maybe
    in the mobile world but explicit proxies are not common there ;

  - the second one is to ensure that browser vendors are not pressured by
    their users to revert the upgrade because it totally breaks what used
    to work for 10 years. And this one seems much more important to me,
    because if Proxy-Connection is still in use after so long a time, it
    precisely is because browser vendors did not find a non-breaking upgrade
    path.

In fact I don't care a dime about NTLM, I hate this broken and insecure
scheme. What I care about is that the spec can *really* be applied. If we
force developers to introduce big regressions, we all know they will revert
the spec, and what we write there is pointless.

A few years ago, I had checked a number of different proxies' behaviour,
and unfortunately I lost the traces since. What I recall is that most of
them mimicked squid's behaviour, which by then was 2.x (I didn't find
this surprizing considering that squid is the de-facto standard proxy).
Among the important points was that an 1.1 request sent without a Connection
or Proxy-Connection header was not considered a persistent connection, which
is normal for an 1.0 proxy and not expected for an 1.1 client. Clients are
already aware of this because they currently send an explicit
"Connection: keep-alive" header.

> Clients choose whether to use persistent connections or not; it's up to them.

That's precisely my point ! If they want to have persistent connections
on an 1.x proxy (where x is unknown), they need to send an explicit
"Connection: keep-alive" header. Without this, they can't chose, not
because of the protocol, but because of currently deployed products'
behaviour which apply 1.0 semantics.

> If you want to make NTLM authentication more interoperable, I'd suggest you create a new I-D describing how to do so.

Oh no, I'm really not interested in this at all, thanks ;-)

Alternatively, maybe this tip could be placed in the section on interoperabilty
with 1.0, because after all it's needed to talk to 1.0 proxies.

Best regards,
Willy

Received on Monday, 5 December 2011 06:37:33 UTC