Re: Keep-Alive Notes

> But: why does anyone thing it makes sense for a server to set
> a session-length timeout of this kind?
> 
> Of course, the timeout value returned in this header might be
> an idle-connection timeout (as I modelled in my SIGCOMM paper).

Yep, that's what it is.

> But this does not seem to be the current intent; I quote from
> Roy's notes:
> 
>     The actual parameters of the Keep-Alive exchange are still unknown
>     and open for experimentation.  The initial idea of using "max" and
>     "timeout" to indicate session-length preference (on requests) and
>     actuals (on responses) is optional.

Ooops -- that's what I get for trying to shorten the explanation.
Timeout is intended to represent the current request idle timeout -- max
is the one indicating maximum session length.  Their purpose is to provide
diagnostic information to the client; that is all.

> and observe that if the client and server have different interpretations
> of the meaning of this timeout, then it's almost certainly useless!

Let's keep in mind that these are only notes -- their purpose is to
examine the possiblities, not define a standard.  What I would like to know
is what has been implemented, why it has been implemented, and thus what
is worth putting in the real specification.

Strangely, everyone seems to be ignoring the part that I thought would
create a maximum of flamage on this topic.  This is particularly amusing
since Dave only pointed out two of the three Keep-Alive parameters
before declaring the Keep-Alive header as unnecessary.

      Keep-Alive: state="Accept,Accept-Language,..."

   for indicating which header fields can be or have been stored as a
   persistent request state.  This would allow the server to decide whether
   or not to be stateless in its request handling, and the amount of state
   it is willing/able to retain, while at the same time allowing each
   request to override the saved state with or without changing what is saved.

I am actually disappointed -- normally such a statement would cause several
keyboards to be worn out in the ensuing debate.  It isn't even well-defined;
plenty of ambiguity in which to engender people's active imagination.


 ...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 Friday, 13 October 1995 17:26:21 UTC