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

Hi Amos,

On Mon, Nov 28, 2011 at 11:20:38PM +1300, Amos Jeffries wrote:
> >I like this. Shouldn't we add something like this :
> >
> >   A proxy receiving an HTTP/1.1 request must ignore Proxy-Connection and
> >   Keep-Alive headers and consider only the Connection header.
> Which brings up the old problem of "Proxy-Connection: keep-alive" 
> passing through middleware which ignores and relays it. End-to-end trouble.

You're right, I was in fact not meaning "relaying it", but "ignoring it when
deciding whether to use persistent connections or not". I'm all for cleaning
up everything we can in the traffic to avoid such trouble.

> Better to mandate that they are both obsolete and thus dropped. Leading 
> to other troubles, but less damaging ones.

Removing it from relayed requests is important. We can just not expect it to
be removed from browser requests without proposing a working alternative,
otherwise browser vendors will get complains that connection to proxies
suddenly break after an update and they will revert it back. For instance,
there are some networks where persistent connectinos are mandatory due to
NTLM auth... I would like to ensure we can help the browser vendors to get
rid of the header without losing persistent conns even when facing old

> For the record Squid drops Keep-Alive ... no problems.
> Proxy-Connection is another story. On Marks request we started dropping 
> it on relayed requests a few years back. Lots of admin questions about 
> where its gone and problems appeared with IIS and a mix of other 
> Microsoft software not handling Connection: in responses to requests 
> sending Proxy-Connection. Yes, I dare to point the finger at MS server 
> software being the sole obvious culprits here, non-MS server software 
> seems to have no problems.

I too recall having observed nasty behaviour on MS software related to this.

> Client software is a different story altogther.

Unfortunately, the client has to adapt to the deployed infrastructure and to
remain compatible with existing bugs. That's why I'm saying that we need to
help clients safely get rid of it first.

> Reports seem to have declined recently, but there are still signs that 
> all this trouble software are still depending on Proxy-Connection acting 
> like Connection. Mostly in the form of traffic traces with 
> Proxy-Connection: and no Connection header.

Agreed, that's what I observed too, and precisely the reason I had to add
an option to haproxy to choose between either header.

> >But at least it seems that Squid falls back to Connection if it does not
> >see Proxy-Connection. It just defaults to close if neither is present,
> >which makes a difference with standard HTTP/1.1, so clients will be tempted
> Since Squid versions which do that are 1.0. That is expected yes?

Yes, 100% agreed.

> The newer versions advertising 1.1 assume keep-alive unless 
> Proxy-Connection, Connection or the config file says otherwise (in that 
> order today). There was a bug in POST/PUT/DELETE keep-alive which we 
> have now resolved.
> >to continue to send "Proxy-Connection: keep-alive" with such proxies. While
> >Squid is quite smart and interoperable, I suspect that other proxies are
> >harder to get right when it comes to the Connection header. So probably 
> >that
> >the Proxy-Connection header will still live for a long time because of this
> >if we don't suggest an alternative solution as above.
> If the agreement here is that it is safe to ignore and drop 
> Proxy-Connection Squid can implement that immediately. The only thing 
> I'm against is ignoring it completely (implying passing it thru).

I agree on this point, and I was not clear in my first response.

Ideally we should try to enumerate the matrix of requests and responses
containing various combinations of Proxy-Connection and Connection values.
It should help match clients' intents with proxies' capabilities. I'm
pretty sure that starting from Squid's behaviour is a good approach as it
has become the de-facto standard, mimmicked by many commercial products.


Received on Monday, 28 November 2011 10:53:24 UTC