Re: Connection Header

Rob McCool <robm@neon.mcom.com> wrote:

> /*
>  * "Re: Connection Header" by frystyk@ptsun00.cern.ch (Henrik Frystyk Nielsen)
>  *    written Sat, 17 Dec 94 16:54:07 +0100
>  * 
>  * The MGET causes an extra roundtrip time as many servers will think:
>  *
>  * 	"Gee - nobody has told me about this method. I simply refuse
>  * to do anything about it"
> 
> It seems to me that this could be alleviated by having regular GET
> methods on MGET-capable servers return
> 
> Allow: MGET
> 
> so that the client, after the first GET, knows whether it should send
> MGET or GET.
> 

MGET and Connection header are not synonyms, The Connection header is
more general than the MGET method as the connection can be used for any
method, for example alternating POST and GET.

Using Allow has the same problem as if a Connection header is passed
through a proxy. Imagine the following setup

	new client      ->      old proxy       ->      new server

On the first request, the new server will then send back a

	Allow: GET, MGET, HEAD, etc.

On the second request, the new client will try a MGET, but the proxy
doesn't understand this and then we are back to the old problem having
lost one roundtrip time. UNDER the assumption that the Proxy server
ALWAYS picks out the Connection header, this problem will not exist.
Otherwise the proxy needs to strip out all methods that it doesn't
understand from the Allow header. I think the first solution is far
easier.

>  * This is the reason for waiting with a SESSION method to HTTP/1.1 as
>  * Roy points out. Also we would like a more general approach than
>  * only having GET as a possibility. A SESSION method can also be used
>  * for interactive sessions.
>  */
> 
> Does the SESSION method you propose allow for servers to mix pieces of
> responses to different requests together like HTTP-NG?

No, in order to do this you need a session layer managing the virtual
connections. I think we should leave this for HTTP-NG. This approach
only allows the server to serve the responses in serial. For the user
it might not be as `efficient' as opening several TCP connections, but
it prevents servers from melt down in which case the user has lost
anyway.

-- cheers --

Henrik

Received on Sunday, 18 December 1994 04:56:34 UTC