W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2009

Keep-alive header in RFC2616

From: Adrien de Croy <adrien@qbik.com>
Date: Mon, 09 Mar 2009 19:25:13 +1300
Message-ID: <49B4B649.6060409@qbik.com>
To: HTTP Working Group <ietf-http-wg@w3.org>

apologies in advance if this is already in the issue tracker - I did 
look but didn't find it.

The Keep-alive header is mentioned in 2 places only in RFC2616.

In section 13.5.1 it is listed as a hop-by-hop header.

In section 8.1.3 it is referred to in the context of persistent 
connections with HTTP/1.0 clients.

By existing in section 13.5.1 it would imply that this is an HTTP/1.1 
header, which appears is not the case.

Perhaps of more importance is the Proxy-Connection header, which is 
still sent by IE, Firefox and Chrome (and many others), even though it 
is not an HTTP/1.1 or HTTP/1.0 header at all!.

There is no reference to this header in RFC2616, its widespread use 
however makes it important.

I would propose:

1. Modify text for 13.5.1 to only refer to HTTP/1.1 headers, or make it 
clear which headers are HTTP/1.0, or being referred to for other (e.g. 
compatibility) reasons.

2. Perhaps in the section on persistent connections with proxies (8.1.3) 
make some mention of Proxy-Connection and how to deal with it.  I note 
there has been discussion on this list about dealing with the header (so 
why it persists is perplexing).

3. Put in a section on deprecated headers.  If the headers are listed 
there, then a search on the header name will find them in that section, 
and people can stop perpetuating these problems.

Is the recommended method to deal with Proxy-Connection simply to treat 
it as a backup for a connection tag (e.g. if there is no Connection tag 
look for a Proxy-Connection tag), but never send one? 

I'm wondering how some proxies deal with lack of a Proxy-connection tag, 
has there been any research done on this?



Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
Received on Monday, 9 March 2009 06:22:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:48 UTC