W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2011

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

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Tue, 29 Nov 2011 00:42:15 +1300
Message-ID: <4ED37397.2030900@treenet.co.nz>
To: Willy Tarreau <w@1wt.eu>
CC: ietf-http-wg@w3.org
On 28/11/2011 11:52 p.m., Willy Tarreau wrote:
> 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
> proxies.
>> 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.

We seem not to have any troubles nowdays emitting only Connection. The 
problems are on satisfying the sources who send Proxy-Connection still. 
IMO it would be nice to have a guideline to point at stating that 
Connection overrides Proxy-Connection and the latter should be ignored 
for processing and never emitted.

Received on Monday, 28 November 2011 11:42:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:54 UTC