Re: NCSA implementation of KeepAlive

> Let me try to summarize:
> 
> (1) Roy insists that the name of the header which carries the
> "timeout" and "max" values is named "Keep-Alive", and nothing
> I can do will change his mind :-).

The header named "Keep-Alive" will carry all options associated
with a minimally persistant connection, whatever those options may be.
In other words, any options that may be implied by the Keep-Alive keyword.

> (2) The Spyglass browser ignores this header, the NCSA browser
> apparently ignores it, and nobody else's browser seems to pay
> any attention, either.

As I said before, it carries *diagnostic* information.  You don't have
to send it, and you don't have to read it, but if you happen to be running
a server for the purpose of testing client behavior (or running a client
in order to test a server implementation) it can be quite useful if
the server is using an adaptive timeout/request scheme to be able to
see the choices without forcing an actual timeout.

> (3) Roy tried to sneak past us a new mechanism that allows the
> server to tell the client what state it will maintain between
> requests on the same connection.

Hah, I had to point it out three times -- not very sneaky.

>    (c) The "stored-state" stuff ought to be carried in a new header
>    named "Stored-state".

That would require a Stored-state keyword for the Connection header,
but that's okay with me; I don't need to include it as part of the
keep-alive mechanism (in fact, I'd rather not).

BTW, "Keep-State" seems like a better name for that.   ;-)
[and no, I won't be including persistant state in HTTP/1.1 until
at least one implementation proves that it is worthwhile]

 ...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/