- From: Roy T. Fielding <fielding@avron.ICS.UCI.EDU>
- Date: Thu, 22 Dec 1994 01:06:40 -0800
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Dave Kristol writes: > Here's another wrinkle to consider for a SESSION method. Some transactions > have a model that resembles the Basic authentication scheme: > 1) The client innocently asks for something. > 2) The server rejects the request and asks for something extra. > 3) The client reissues the original request, plus the something extra. > 4) The server honors the request. > > This model applies for some payment schemes and some security schemes. It > would be nice if the client had a way to tell the server it's willing to > keep a connect open (create a session), even though it didn't request to do > so at first (with a SESSION method). Perhaps the client can send the same > Connection: headers that it would have sent with a SESSION method. Yes, that is the intention. The Connection header (on ANY request) would be used to indicate connection options requested by the client, and on the response it would indicate what connection options were accepted by the server. The SESSION method would simply be a way to initiate a conversation with the nearest neighbor without performing some action on an object, and avoiding the message being forwarded downstream. Note that this is different than what was originally proposed at the BOF -- the design changed due to the discussions we had there. The SESSION method does not, in and of itself, constitute a continuous connection, though it may include a Connection header which requests that option. This is very similar to the NULL method used by SHEN, but applies only to the nearest neighbor. Would it help if we used a different name? Any suggestions? ......Roy Fielding ICS Grad Student, University of California, Irvine USA <fielding@ics.uci.edu> <URL:http://www.ics.uci.edu/dir/grad/Software/fielding>
Received on Thursday, 22 December 1994 01:08:56 UTC