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: Mon, 28 Nov 2011 23:20:38 +1300
Message-ID: <4ED36076.6080509@treenet.co.nz>
To: ietf-http-wg@w3.org
On 28/11/2011 8:01 p.m., Willy Tarreau wrote:
> Hi Mark,
>
> On Mon, Nov 28, 2011 at 03:44:40PM +1100, Mark Nottingham wrote:
>> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/158>
>>
>> Description:
>>
>>> The Keep-Alive header is referred to in a few places, but not defined as a HTTP/1.1 header. This should be addressed (e.g., in an appendix).
>>>
>>> Likewise, Proxy-Connection is still (!) in common use, but has been deprecated for at least a decade. A few words in an appendix may encourage implementers to stop this practice.
>> We already have text in p1 about Keep-Alive, so it seemed best to just modify it slightly to also cover Proxy-Connection. I made a proposal on-ticke:
>>
>>> Proposal - replace p1 A.1.2 with:
>>>
>>> Most HTTP/1.0 implementations use a separate connection for each request. However, some implement persistent connections using the Keep-Alive negotiation mechanism described in Section 19.7.1 of [RFC2068].
>>>
>>> In contrast, persistent connections are the default for HTTP/1.1; they do not need to be explicitly negotiated, as in HTTP/1.0. This is because there were various interoperability problems in the implementations of HTTP/1.0 persistent connections, especially when a proxy is involved.
>>>
>>> For example, some existing HTTP/1.0 clients might send Keep-Alive to a proxy server that doesn't understand Connection, which would then erroneously forward it to the next inbound server, which would establish the Keep-Alive connection and result in a hung HTTP/1.0 proxy waiting for the close on the response. The result is that HTTP/1.0 clients must be prevented from using Keep-Alive when talking to proxies.
>>>
>>> However, talking to proxies is the most important use of persistent connections, so that prohibition is clearly unacceptable. Some early attempts to correct this was to use the Proxy-Connection request header, but this approach was also unworkable, for similar reasons.
>>>
>>> Therefore, some other mechanism for indicating a persistent connection was needed -- one that is safe to use even when talking to an old proxy that ignores Connection. Persistent connections are the default for HTTP/1.1 messages; we introduce a new keyword (Connection: close) for declaring non-persistence. See Section 8.1.
>>>
>>> As a result, HTTP/1.1 clients ought not to send the Proxy-Connection or Keep-Alive header; at best, they will waste bytes in requests, and at worst they can cause interoperability problems.
>> We should also probably register Proxy-Connection with a status of "obsoleted".
>>
>> Comments?
> 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.

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

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. Client software is a different story altogther.

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.

> and :
>
>    A client wishing to use persistent connections with a proxy running an
>    unknown HTTP version may explicitly send "Connection: keep-alive". This
>    statement will be silently ignored by 1.1 proxies and will enable use of
>    persistent connections on 1.0 proxies which understand the Connection header.
>
> I've encountered a number of issues when deploying haproxy as an intermediary
> between some clients and ancient Squid versions which made me use the
> Proxy-Connection header only in this case because the Connection header was
> not always usable. From what I recall, the issue appeared if haproxy only
> altered the connection header and not the proxy-connection, because both the
> proxy and the client would consider only the later.
>
> It's easy to notice in a response that it's HTTP/1.0, but in the request,
> the client speaks 1.1 and the intermediary does not know the next hop will
> prefer Proxy-Connection over Connection.
>
> For instance, if I send this to my local squid 2.6-stable13 :
>
>    HEAD http://www.yahoo.fr/ HTTP/1.1
>    Host: www.yahoo.fr
>    Proxy-connection: keep-alive
>    Connection: close
>
> The connection remains alive in the response :
>
>    HTTP/1.0 301 Moved Permanently
>    Date: Mon, 28 Nov 2011 06:39:55 GMT
>    P3P: policyref="http://info.yahoo.com/w3c/p3p.xml", CP="CAO DSP COR CUR ADM DEV TAI PSA PSD IVAi IVDi CONi TELo OTPi OUR DELi SAMi OTRi UNRi PUBi IND PHY ONL UNI PUR FIN COM NAV INT DEM CNT STA POL HEA PRE LOC GOV"
>    Cache-Control: max-age=3600
>    Location: http://fr.yahoo.com/
>    Vary: Accept-Encoding
>    Content-Type: text/html; charset=utf-8
>    Age: 165
>    Content-Length: 81
>    Server: YTS/1.19.5
>    X-Cache: MISS from px.home.local
>    Via: HTTP/1.1 rc1.ops.ird.yahoo.com (YahooTrafficServer/1.19.5 [cHs f ]), 1.0 px.home.local:3128 (squid/2.6.STABLE13)
>    Proxy-Connection: keep-alive
>
> 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?

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

Amos
Received on Monday, 28 November 2011 10:21:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:50 GMT