- From: J.P. Martin-Flatin <martin-flatin@epfl.ch>
- Date: Wed, 29 Jul 1998 18:10:42 +0200
- To: http-wg@cuckoo.hpl.hp.com
- Cc: Jim Gettys <jg@pa.dec.com>, martin-flatin@epfl.ch
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-
token:
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.
Thanks
Jean-Philippe
____________________________________________________________________
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