W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1995

Re: Keep-Alive Notes

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Thu, 19 Oct 95 11:34:21 MDT
Message-Id: <9510191834.AA05350@acetes.pa.dec.com>
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 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:34 EDT