- From: Roy T. Fielding <fielding@avron.ICS.UCI.EDU>
- Date: Wed, 18 Oct 1995 13:28:41 -0700
- To: Simon Spero <ses@tipper.oit.unc.edu>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
> I'll describe the HTTP-NG approach to the issue of header caching as used
> in 1.0->NG->1.0 relay mode.
>
> Each request takes place in a Context; a context is a bunch of state
> associated with a set of requests. When a client proxy relays a 1.0
> request, it can set a boolean indicating whether headers should be
> reused or not. If headers are reused, then any request headers sent with
> this request are merged with those used for the previous request; if a
> header is not sent, then its value is reused as is; if they are sent then
> the value is replaced.
You could do this in 1.1 with a context="save" and context="use" params.
The problem is how does the server control how much context it is willing
to save, and given that, how does it inform the client of the current
context *before* the client's next request. Assuming that the server
is willing to store arbitrary context (state) is a non-starter -- it
violates fundamental client-server design principles.
The remaining choices are to never retain state (and thus keep HTTP stateless)
or allow the server to decide what state will be retained. Aside from the
additional complexity of implementation, the latter has a further deficiency
in that it disallows pipelining of requests.
What I am left with is a design quandary. The only solution I can think
of is to include all three possibilities in the initial drafts and then
have a bake-off to determine which partitions are left in the standard.
...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 Wednesday, 18 October 1995 13:55:30 UTC