W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1996

Re: PERSIST: headers needed at all?

From: Dave Kristol <dmk@allegra.att.com>
Date: Tue, 16 Apr 96 09:21:40 EDT
Message-Id: <9604161321.AA00361@zp.tempo.att.com.tempo.att.com>
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
I don't have real strong feelings about pushing on this idea.
It just seemed like a nice simplifying assumption.  I realize it's
a bit late in the game to propose such a change.

Jeffrey Mogul <mogul@pa.dec.com> wrote (in part):

  > 	(2) more subtly, the existing proposal does not allow a client
  > 	to pipeline its requests unless it has received a Persist:
  > 	header from the server.  "Pipeline" means "send multiple
  > 	requests before receiving any responses.  So we would also have
  > 	to make sure that there was never any reason that a 1.1 server
  > 	could not handle such behavior.  As I said, up to now we
  > 	have not tried to obtain near-unanimous consent for this.

An HTTP/1.1 response would signal that pipelining further requests after
the first is possible.  There is the question of what the client should
do if the server closes the connection (because it only wanted to handle
a single request) while the client is trying to send a train of further
requests.  I don't know the answer.

[...]
  > The Connection header is there for orthogonal extensibility reasons.
  > Its purpose is to allow HTTP/1.1 caches to ignore future hop-by-hop
  > headers that may be defined in HTTP/1.x.  Roy added it to HTTP/1.1
  > because he observed that if it had been in HTTP/1.0, we could have
  > more easily added persistent-connection support in a compatible way.

Yes, and that function could presumably be retained.  But an origin
server need not look for it.

"Roy T. Fielding" <fielding@avron.ICS.UCI.EDU> wrote (in part):

  > I think the deciding issue is the problem of writing to a socket
  > after the other end has attempted to close it (but the close has
  > not yet reached the writer).  It is difficult to handle such an event
  > because there is no indication of why the socket was closed or
  > when (without looking at the TCP ack sequence, which generally isn't
  > available to the HTTP programmer).  If we could come up with a decidable
  > set of rules for what to do when the connection closes and the
  > client isn't expecting it to close, then I suppose we could do without
  > the Persist header.

All true.  And yet, there's always the danger that the connection to
the client might close unexpectedly, and the client would have to
recover gracefully.  Would adopting my proposal make the situation
worse?

Dave
Received on Tuesday, 16 April 1996 06:28:34 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:50 EDT