Re: PERSIST: headers needed at all?

One problem is that there is a cost associated with holding a
connection open on the server.  If the client knows that it will
not be reusing the connection after the current request, then not
asking for persistence means that the server can switch its process
resources to a new connection immediately after sending the last
response (as opposed to waiting for the close or timeout from the
client).  On the other hand, one might say that if the server is
reaching its resource constraints, then it can close the connection
anyway.

There are some clients that will not want to implement more than one
request per connection (batch-mode and text-only clients in particular)
and yet will want to take advantage of the other features of HTTP/1.1.
Although they could do so even with your proposal, their inability
to signal that they did not want persistence would use up server
resources unnecessarily.

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.

 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92717-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/

Received on Monday, 15 April 1996 20:50:42 UTC