- From: Alexei Kosut <akosut@nueva.pvt.k12.ca.us>
- Date: Thu, 22 Feb 1996 13:26:44 -0800 (PST)
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
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? Thanks --/ Alexei Kosut <akosut@nueva.pvt.k12.ca.us> /--------/ Lefler on IRC ----------------------------/ <http://www.nueva.pvt.k12.ca.us/~akosut/> 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