Re: I-D ACTION:draft-ietf-http-ses-ext-01.txt

On Thu, 22 Feb 1996 Internet-Drafts@CNRI.Reston.VA.US wrote:

> A Revised Internet-Draft is available from the on-line Internet-Drafts 
> directories. This draft is a work item of the HyperText Transfer Protocol 
> Working Group of the IETF.                                                 
>        Title     : Persistent HTTP Connections                             

First, I must say this draft looks very good. However, I do have some 
comments, or at least a request for clarification:

Section 1.4 deals with "Sticky Headers", saying that the client can 
request them by inserting a "sticky" token in the Connection: header, and 
the server will respond with same. However, the first example in section 
2 does not follow this.

Namely, the client sends "Connection: persist", and the server then 
responds. Then the client says "GET /mying.jpg HTTP/1.1" and no request 
headers. Since sticky headers have not been turned on, the comment that 
the server should be "using same accept: values as the first request" is 
incorrect. Furthurmore, since the Connection: and Persist: headers are 
not among those kept with sticky headers, the connection (even were 
sticky headers on) should not be kept open. But it does.

It seems like this is an editorial error, especially since in the next 
request, the client *does* again send Connection: and Persist:. But I 
could be misreading the text. If some clarification could be obtained, 
that would be wonderful.

My other question is this: sections 1.2, 1.3 and 1.5 contain strict
warnings against using the specification with HTTP/1.0. However, it seems
to me that, assuming the hostname given in the Persist: header is checked
carefully by the server, there is no reason the protocol would not work as
an extension to HTTP/1.0, in addition to being part of HTTP/1.1. Is there
some factor I am overlooking?


--/ Alexei Kosut <> /--------/ Lefler on IRC
----------------------------/ <>
The viewpoints expressed above are entirely false, and in no way
represent Alexei Kosut nor any other person or entity. /--------------

Received on Thursday, 22 February 1996 13:30:09 UTC