W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1998

Re: Connection tokens

From: J.P. Martin-Flatin <martin-flatin@epfl.ch>
Date: Wed, 29 Jul 1998 18:10:42 +0200
Message-Id: <199807291610.SAA20101@tcomhp31.epfl.ch>
To: http-wg@cuckoo.hpl.hp.com
Cc: Jim Gettys <jg@pa.dec.com>, martin-flatin@epfl.ch
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/273
On Fri, 17 Jul 1998 11:02:55 -0700, Jim Gettys wrote:
> A couple things wrong with this suggested rewrite:
> 1) saying it is vague is unfair; the spec says that 1.1 defines the
> token "close" very clearly.

I agree that the token "close" is defined clearly.

> 2) Keep-Alive is a header.

You missed my point: in RFC 2068, section 19.7.1 states that Keep-Alive 
and Persist are connection-token's. Here's the original text:

   When it connects to an origin server, an HTTP client MAY send the
   Keep-Alive connection-token in addition to the Persist connection-

          Connection: Keep-Alive

> 3) as HTTP/1.1 may be extended in ways that are just as valid as
> the base spec, saying that close is the only connection token is
> I believe misleading, as others may want/need to define other tokens;
> I don't want the base spec to imply that some other spec isn't as valid
> that is extending HTTP/1.1.

I disagree: I don't think different implementations should be allowed to 
use their own proprietary tokens. Allowing this would result in 
interoperability issues.

> I did add cross references in the section to section 19.6.2, and
> vice versa, where persistent connection compatibility with HTTP/1.1
> is discussed, which should reduce confusion.


Jean-Philippe Martin-Flatin, EPFL-DI-ICA, 1015 Lausanne, Switzerland
Email: martin-flatin@epfl.ch                    Fax: +41-21-693-6610
Web: http://icawww.epfl.ch/~jpmf/
Received on Thursday, 30 July 1998 09:12:49 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:22 UTC