W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 1994

Re: Connection Header

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
Message-Id: <9412220106.aa16046@paris.ics.uci.edu>
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
Received on Thursday, 22 December 1994 01:08:56 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:42:54 UTC