Re: Keep-Alive Notes

> If the proxy is a caching proxy, the proxy - server connection will be used less
> frequently, than the client - proxy connection.

Yes, that is the intention.

> If there are multiple clients accessing the same orig server, the proxy may want
> to multiplex requests from different clients in one server connection. For this
> case the keep-alive header isn't the best place to carry the accept*
> configuration.

On the contrary, that is exactly why the keep-alive header is the best
place to indicate what can be kept as state.  When the proxy switches
the request to a different client, it must replace any preexisiting state
with that of the current request, which is why the state="" parameter
is a list of header field-names.

> (Graphical browsers have two set of accept* headers, one for web 
> pages, one for inlined images. This is a second objection to
> keep-alive: state=....)

Again, that is why it exists in the first place, as opposed to just
an assumption that state be inherited, or not exist at all.  For example

First request:  get the object and save browser default accept list

    GET / HTTP/1.1
    Connection: Keep-Alive
    Accept: text/*, */*;q=0.1
    Accept-Language: en, mi
    Keep-Alive: state="Accept,Accept-Language"

    HTTP/1.1 200 OK
    Connection: Keep-Alive
    Keep-Alive: timeout=20, state="Accept,Accept-Language"
    ...

Second request:  get an image, override current Accept

    GET /image1 HTTP/1.1
    Connection: Keep-Alive
    Accept: image/gif, image/jpeg, image/*;q=0.1

    HTTP/1.1 200 OK
    Connection: Keep-Alive
    Keep-Alive: timeout=20, state="Accept,Accept-Language"
    ...

Third request (new client): replace state with its own

    GET / HTTP/1.1
    Connection: Keep-Alive
    Accept: application/pdf, text/*, */*;q=0.1
    Accept-Language: fr, de
    Accept-Charset: UNICODE-1-1, iso-8859-1
    Keep-Alive: state="Accept,Accept-Language"

    HTTP/1.1 200 OK
    Connection: Keep-Alive
    Keep-Alive: timeout=20, state="Accept,Accept-Language,Accept-Charset"
    ...

The more I look at such gross stuff, the more I feel we should just
ditch the whole Accept* nonsense and implement two-phase negotiation
instead.  Hmmm, in that case, we would be better-off without state="".

> The accept-signature (or accept-hash) proposed by Larry
> Masinter looks better.

Only if you assume that the accept headers will never be configurable
on a per-client basis, in which case we might as well get rid of them
altogether.


 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92717-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/

Received on Monday, 16 October 1995 18:24:46 UTC