Re: Keep-Alive Notes

What about this:

Client sends request with context.  Let's assume that the server only 
has a problem with how much context it can store, but not which parts 
it is asked to save -- if necessary, spec which headers *must* be 
allowed to be in the context if the server has room.

If the server doesn't have space, it sends back a new error: Too Much 
Context (is it a 3xx error, indicating "further action needs to be 
taken by the user agent to fulfill the requiest" or 4xx error, 
indicating "client erred"?)  The client is obliged to reduce the amount 
of context it asks for, and try again.  If requests are "sent-ahead" 
because the client is pipelining, then it may get several "Too Much 
Context" errors while the round trip is happening.  However, the 
correct amount of context will be determined when the first resource is 
fetched from a server, which is before it has any info to use to fill a 
pipeline -- e.g., before it fetches the first .html from a server, it 
doesn't know which inline .gifs to start fetching in a pipelined manner.
----------
] From: "Roy T. Fielding"  <fielding@avron.ICS.UCI.EDU>
] To: Simon Spero  <ses@tipper.oit.unc.edu>
] Cc:  <netmail!http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
] Subject: Re: Keep-Alive Notes
] Date: Wednesday, October 18, 1995 1:28PM
]
] > 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 23:17:54 UTC