- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Tue, 29 Nov 2011 00:42:15 +1300
- 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. Amos
Received on Monday, 28 November 2011 11:42:57 UTC