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

Re: PERSIST: headers needed at all?

From: Albert Lunde <Albert-Lunde@nwu.edu>
Date: Tue, 16 Apr 1996 10:15:45 -0500 (CDT)
Message-Id: <199604161515.AA154137745@merle.acns.nwu.edu>
To: Dave Kristol <dmk@allegra.att.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/237
> "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?

It seems like the "worst case" is the same, but the "average case"
for a server that really doesn't want to do persistent connections
is worse. If the client and server have similar "expectations"
I'd think there would be fewer connections closed ungracefully.

I'm not sure where the side effects of this would fall out, though.

    Albert Lunde                      Albert-Lunde@nwu.edu
Received on Tuesday, 16 April 1996 08:21:00 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:16 UTC