Re: #282: Recommend minimum sizes for protocol elements

On 25/06/2011, at 4:58 PM, Poul-Henning Kamp wrote:

> In message <196C8694-5F50-42E8-8194-493093FD388E@mnot.net>, Mark Nottingham wri
> tes:
> 
>> Just to be clear -- we're talking about the total size of the *entire* =
>> header block here, not a single header limit.
>> 
>> Were the folks arguing for 4k assuming the former or the latter?
> 
> I do not think we can set any numerical value for this property
> which will satisfy everybody, but 4k is a sensible compromise between
> seriously memory-starved gadgets (your future electricity meter)
> and a reasonable level of cookie state, which surprisingly many of
> these gadgets use.

Considering that there isn't any floor at the moment, I'm optimistic.


> Would this be too evil ?
> 
> 	If the underlying transport protocol advertises or negotiates
> 	a receive buffer size, such as the TCP window, Clients
> 	SHOULD NOT send HTTP requests larger than this size.
> 
> This would allow really tiny implementations, such as Contiki, to
> inform the world about their limits.

That ignores proxies; the window size is effectively hop-by-hop (from an HTTP standpoint), and anyway this will cause people to complain about layer violations.


> A server is still free to set a huge window to speed up POST, without
> committing to accepting 2MB requests.
> 
> In most sensible socket implementations, socketoptions are inherited
> from your accept socket to the accepted sockets, so a single setsockopt
> can configure this on the server side.
> 
> I realize that not all socket implementations allow you to inspect
> this number with getsockopt, but maybe this can inspire some kernel
> network coders to provide that.
> 
> Also, I assume it is obvious to everybody, that the header size we
> are talking about includes the two CRNL sequences at the end ?


We'll need to go to that level of detail when we write the text, yes. It seems reasonable to include it.

--
Mark Nottingham   http://www.mnot.net/