Re: #282: Recommend minimum sizes for protocol elements

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.


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.

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 ?


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Received on Saturday, 25 June 2011 06:58:34 UTC