Re: Call for Consensus: Frame size (to address #553)

In message <>, Yoav Nir writes:

>> In message <>, Jeff Pinner writes:
>>> So am I to read this as a client might advertise a max frame size of
>>> 256 bytes and then request a 2GB file?
>> yes.
>> And the server is free to return 418 or react in any other way it might
>> find appropriate.
>'free to' yes, but if we're going to say that clients advertise a 
>max frame size that MUST be at least 256 bytes, then we should have a 
>SHOULD-level requirement for servers to work with such a limit.

How is a client advertising 256 bytes different from a server
advertising a 256 byte max frame ?

And what exactly would the SHOULD level requirement make anybody do
differently anyway ?

>If we think that 256 bytes is too low to require servers to work with, 
>then maybe we should set the min-max-frame to something higher, [...]

Why should we force applications for whom 256 is plenty to use something
higher ?  Who gains anything by us doing so ?  And if we insist on some
lower limit which is onerous for tiny devices, do you think they are
going to spend 8 times more for their microcontroller or ignore what
we say ?

The 256 limit is simply to make sure that any HTTP/2 implementation will
always support "GET /" and "GET /robots.txt" and nothing more.

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 Monday, 14 July 2014 09:21:36 UTC