Re: PERSIST: Made default

Thanks for doing that; I have just a few comments:

(1) The word "pipeline" is an accepted word in English, and therefore
should not be hyphenated.  Please replace "pipe-line" with "pipeline",
including all inflections.  (A global replace of "ipe-lin" with "ipelin"
should do the trick.)

(2)
    + An HTTP/1.1 server MAY assume that a HTTP/1.1 client maintains a
    + persistent connection unless a Connection header including the
    + connection-token "Close" was sent in the request. If the server
    + chooses to close the connection, it SHOULD send a Connection header
    + including the connection-token "Close".

I would change this to make it clearer that a server or client is always
allowed to close a connection between requests:

    + An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends
    to maintain a
    + persistent connection unless a Connection header including the
    + connection-token "Close" was sent in the request. If the server
    + chooses to close the connection
    immediately after sending the response, 
    it SHOULD send a Connection header
    + including the connection-token "Close".

(3)    
    17.2.3 Delimiting Entity-Bodies
    When using persistent connections, both the client and the server MUST
    mark the exact endings of transmitted entity-bodies using one of the
    following three techniques:
    
Actually, there's a fourth technique (albeit still the subject of
some controversy) if the Content-Range section (18.18) is to be
believed:

      1. Send a Content-length field in the header with the exact number of
	 bytes in the entity-body.
      2. Send the message using chunked Transfer Coding as described in
	 section 7.6. Chunked Transfer Coding allows the server to transmit
	 the data to the client a piece at a time while still communicating
	 an exact ending of the entity-body.

+     3. Send the message using the the MIME multipart/byteranges
+	Content-type, which is self-delimiting.  This Content-type
+	MUST NOT be used unless the sender knows that the recipient
+	can parse it; the presence in a request of a Range header
+	with multiple byte-range specifiers implies that the client
+	can parse multipart/byteranges responses.

-     3. Close the transport connection after the entity body.
+     4. Close the transport connection after the entity body.
    
    + Sending the Content-length is the preferred technique. Chunked
    + encoding SHOULD be used when the size of the entity-body is not known
    + before beginning to transmit the entity-body. Finally, if neither 1
    + or 2 are possible then the connection SHOULD be closed. Note that the
    + last method does not work if the entity-body is part of a request.

should be "none of 1, 2, or 3 is possible"

By the way, I checked with Netscape yesterday and was informed that
they already implement and successfully use multipart/byteranges to
return multi-range responses over persistent connections.

(4)
    - 18.33 Persist

Just a note: I'm not opposed to deleting the Persist header, but this
removes the possibility of associating parameters with the persistent
connection mechanism, and some people have suggested that such parameters
are useful.

(5)
    + Some clients and servers may wish to be compatible with some previous
    + implementations of persistent connections in HTTP/1.0 clients and
    + servers. Persistent connections in HTTP/1.0 must be explicitly
    + negotiated as they are not the default behavior. HTTP/1.0
    + implementations are faulty, and the new facilities in HTTP/1.1 are
    + designed to rectify these problems.  The fear was that some existing
    + 1.0 clients may be sending Keep-Alive to a proxy server that doesn't
    + understand Connection, which would then erroneously forward
    
I think "HTTP/1.0 implementations are faulty" isn't quite what was
meant here in the original language.  Try "HTTP/1.0 experimental
implementations of peristent connections are faulty".

Also, Dan DuBois informs me that this is not simply a "fear", but
actually occurs in practice.  So the last sentence should start:

    The problem was that 1.0 clients that send Keep-Alive could send it
    to a proxy server that doesn't understand Connection, which would
    then erroneously forward

-Jeff

Received on Friday, 24 May 1996 12:15:50 UTC