- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Thu, 19 Oct 95 11:34:21 MDT
- To: Paul Leach <paulle@microsoft.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
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.
When faced with an analogous problem, the designers of the IP protocol
solved it by arbitrary fiat:
Every internet destination must be able to receive a datagram of 576
octets either in one piece or in fragments to be reassembled.
Implicit here is the rule that implementations wishing to exchange
larger datagrams must either make prior arrangements as part of
a higher-level protocol, or negotiate the datagram size at run-time
(as TCP does with the MSS option).
This doesn't make everyone happy; just the other day, someone came
to me complaining that he couldn't implement BOOTP in a system with
just 512 bytes of RAM. But by setting a reasonable lower bound, it
resolves a lot of debate.
How about something like this:
A server must be able to accept and retain at least
8K bytes of context (as encoded on the wire); it may
accept more.
A server may indicate its willingness to accept more
than 8K bytes with a Context-Size-Accepted: header.
Once the server has indicated an acceptable size, it
may not shrink this value for the current connection.
The context-size limit applies to the sum of all contexts
in use for a given connection.
The "8K bytes" value is just for illustration; I have no idea
how big contexts are in "real life." I would imagine that however
big they are today, they might possibly be 10 times bigger a few
years from now, so we ought not to be too stingy here. To me,
8K bytes seems like a rather piddling amount (any reasonably
equipped server is going to allow several times that much for
TCP buffers, per connection).
We might want to add one escape clause for minimal servers:
A server may choose not to implement the context mechanism.
In that case, it must respond to any "context save" parameters
with a warning code (TBS), and to any "context use" parameters
with an error code (TBS). Clients receiving such an error
in response to a request must resubmit the request, without
context information. Clients should remember which servers
do not accept context information, for up to 1 day.
The (arbitrary) 1 day limit allows a server to be upgraded without
waiting too long for the clients to realize that it now accepts
context information. One failed request per day per client seems
to be an acceptable price to pay for the ability to upgrade the
server.
-Jeff
Received on Thursday, 19 October 1995 11:54:01 UTC