- From: M. Hedlund <hedlund@best.com>
- Date: Thu, 22 Feb 1996 17:14:44 -0800 (PST)
- To: BearHeart / Bill Weinman <bearheart@bearnet.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
First of all, I'd like to remind everyone that there is a state management subgroup to this working group, and that we've worked over the past few months to produce an Internet Draft (which was submitted today). While I agree that we should review Phillip's draft and see what it has to offer, I am frustrated to see two parallel development efforts without a clear sense of the differences between them. Please follow up any process comments related to the above paragraph to myself and the working group chairs, _not_ to the list as a whole. Include Phillip and <state@xent.w3.org> if you do. On Thu, 22 Feb 1996, BearHeart / Bill Weinman wrote: > 1) A specification for a CGI variable that would indicate > to a CGI program that a session is persistent. Perhaps called > SERVER_CONNECTION it would have the content of the *server's* > Connection: header for the last transaction. Using this with the > HTTP_CONNECTION variable would allow a CGI program to determine > if it's dealing with a persistent connection. > > This information would be useful for CGI state management. I can't see why it would be useful. Could you please give an example? > 2) A method for a CGI program to originate request for a > persistent connection. Simply make the protocol bi-directional. > If the server originates a "Connection: persist" to the client, > the client may respond back with "Connection: persist" and the > exchanges could continue as already specified. This makes no sense to me. Why would a server or a server extension want to request a persistent connection from a client that did not indicate persistent capabilities? Marc Hedlund <marc@organic.com> <hedlund@best.com>
Received on Thursday, 22 February 1996 17:16:56 UTC