- From: Dave Kristol <dmk@allegra.att.com>
- Date: Mon, 19 Dec 94 09:57:14 EST
- To: fielding@ics.uci.edu
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
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. If I understand the SESSION proposal correctly, the client must wait until the server responds before it can send its first "real" request. Wouldn't it make more sense to be able to send the first "real" request along with the SESSION request? If so, we're starting to look like my extensions proposal (http://www.research.att.com/~dmk/extend.txt, which needs some polishing per Larry Masinter's suggestion at IETF), in which you can "wrap" requests in layers. In this instance, SESSION resembles my WRAPPED request, and the contained request(s) is(are) the "real" request. Dave Kristol
Received on Monday, 19 December 1994 17:32:23 UTC