- 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>
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