Connection Header

I knew I should have replied to these messages yesterday,
but the need for sleep got the better of me.  Enabling multiple
requests on a single connection will be the primary goal for HTTP/1.1.
However, before that happens, we needed a solid basis for HTTP/1.0 --
one which is compatible with correct current practice and yet does
not prevent future extensibility.  Thus, in the process of writing
HTTP/1.0, Henrik and I have been figuring out what needs to be done
for HTTP/1.1.  In this way, we have identified several aspects of
"current practice" which must be fixed before standardizing 1.0.
Most of these we have already talked about (i.e. being able to parse
media types correctly so that parameters can be used, enabling
something other than a closed connection to mean end-of-body, etc.).

Simon briefly mentioned another problem that we have yet to discuss
on the mailing list:

> One other thing that was discussed was the relative advantages of using a 
> session method vs. an ignorable header. It turns out that there is a problem
> with using ignorable headers when proxies are used - if a proxy which doesn't
> interpret the header is used to talk to a server which does handle the header,
> the connection can become deadlocked (the end server things that the 
> proxy doesn't want it to drop the connection, whilst the proxy is sitting
> there waiting for the connection to drop). 

As always, all the real work at the IETF was done in the hallways, so
many of you at the BOF may not have heard about this either.  The essential
problem is that HTTP intermediaries (proxies) treat everything they
don't understand as being something they should pass on to the destination
host.  Unfortunately, that means they would pass on stuff that was only
intended for them (like connection setup information), thus fooling the
end-server into thinking that the proxy wants that connection setup applied.
Worse, I believe this applies equally for both ignorable headers and
unknown methods!

Thus, we need a way for all proxies/servers, both HTTP/1.0 and 1.1, to be
able to identify information which must not be passed downstream.  Henrik
and I (with help from many others, some of whom have asked to remain
anonymous ;-) worked out a possible solution in two parts:


1) a SESSION method

   Like what was discussed at the BOF, except current proxies would
   be changed such that no SESSION requests were passed-on -- in effect,
   this would be the same as a NOP command, but allow connection info
   to be passed in the headers.

2) a Connection header

   The Connection header is used to specify the parameters (desired or actual)
   of the current connection. Clients can use this header to indicate
   their desire to use a set of connection options. Servers can use this
   header to indicate what options are actually being applied.  This
   field applies only to the current connection -- receivers should not
   cache or otherwise save the connection information after the
   connection is closed. Proxies must not forward this header, though
   they may generate a separate Connection header for their own

      Connection      = "Connection" ":" 1#connect-option
      connect-option  = token [ "=" word ]

   Although HTTP/1.0 clients and servers do not make use of the
   Connection header outside of experiments, this field will be necessary
   to enable future extensibility of connection-specific behavior. Most
   importantly, HTTP/1.0 proxies need to know that they must not forward
   this header even when they do not understand or make use of its
   contents. For example, an experimental client may send:

      Connection: keep-alive

   to indicate that it desires to keep the connection open for multiple
   requests. The server may then respond with a message containing:

      Connection: keep-alive, timeout=10, maxreq=5
   to indicate that the connection will be kept open for a maximum of 5
   requests, but will timeout if the next request is not received within
   10 seconds. Note that the semantics of these options are not defined
   for HTTP/1.0, though similar options may be defined by future versions
   of HTTP.


Note that the above two are independent -- a Connection header could
be applied to a GET, HEAD, PUT, POST, etc.  It does require a change to
current practice, but only for proxies.  Personally, I can't think of any
other way of doing it without disallowing proxies altogether.

The above is what I plan on putting in the next draft of the HTTP/1.0 spec.
Now would be a good time to hack it to pieces, if you are so inclined.

One idea that has been mentioned is that the Connection header should
be a list of other header-names, thus allowing complete flexibility.
I do not favor that approach, however, because 

   a) it adds more overhead to the request
   b) it would require more work on the part of proxies, and
   c) it would require that Connection be the first header received
      (of those named).

Comments, please?

......Roy Fielding   ICS Grad Student, University of California, Irvine  USA

Received on Friday, 16 December 1994 17:58:24 UTC