Re: HTTP Session Extension draft

Re: http://ugly.resnova.com/draft-ietf-http-ses-ext-00.txt

You asked for comments:

(1) section 1.2:
>   When using the Session Extension both the client and the server must 
>   obey one of the following two rules in order to transmit an entity 
>   body:
>
>   either [send valid content-length or use boundary marker]

A server MUST have the option of closing the connection after the
response to any request, purely for resource-allocation reasons.

Additionally, I believe the server should be allowed to close the
connection if it can't use one of the other two methods (for example,
if the response is the output of a subprocess).

So I think section 1.2 should simply state that the server
	(1) if using content-length, MUST provide an exact value
	(2) SHOULD use content-length or boundary marker
	(3) MAY close the connection after the response.

(1) section 1.3  Proxy Servers:
>   The Session Extension needs special provisions for proxy servers. If
>   a client connects to a proxy server, it must send a header field with
>   the value:
>
>   Connection: maintain-proxy
>
>   Otherwise a non-compliant proxy will simply pass the message on to
>   the destination server. The client and the destination server will
>   each act as if they have a session, while the proxy in between will
>   not honor the session extension. A non-proxy server must NOT respond
>   to the Connection: maintain-proxy header line.
>
>   A proxy server should add to the response it returns to the client
>   the same "Connection: maintain-proxy" field to tell the client that a
>   session between the client and the proxy server has been established.
>   A proxy can then independently negotiate the session extension, if it
>   wishes to, with other destination servers. Note that the Session 
>   Extension does not require that a proxy server negotiate the Session
>   Extension in its own communications with destination servers.

I don't see how this is going to work.  Consider the case of a naive
proxy.  It will simply forward the "Connection: maintain-proxy" header
fields back and forth, right?

Unless you are proposing that the client must know if the proxy
is compliant with your proposal.  But then you are implicitly requiring
either proper configuration or a special protocol that allows the
client to figure this out.

When Simon pointed out this problem, I suggested that a timer-based
approach might work.  I went ahead and simulated it; the results are
in my forthcoming SIGCOMM paper, a version of which can be found at
    http://www.research.digital.com/wrl/techreports/abstracts/95.4.html

This paper also examines the effects of a range of server timeout values.
Note also that while section 1.6 ("Practical Considerations") mentions
only server timeout values, a practical server will probably also have a
quota of active connections, and therefore will need some policy to
close connections when this quota is exhausted.  My simulations show
that LRU works, but I did not investigate other options.

-Jeff

Received on Wednesday, 5 July 1995 11:38:43 UTC