W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

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

From: Poul-Henning Kamp <phk@phk.freebsd.dk>
Date: Mon, 14 Jul 2014 09:21:13 +0000
To: Yoav Nir <ynir.ietf@gmail.com>
cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <39815.1405329673@critter.freebsd.dk>
In message <8E722FAA-1157-4638-AC25-96A756CE93E9@gmail.com>, Yoav Nir writes:

>> In message <CA+pLO_h2799vs37eY1HaSnBUmcGkGW-tmjTCJe1WeKZJRAtQGA@mail.gmail.com>, 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

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:09 UTC