- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Mon, 14 Jul 2014 20:38:55 +0000
- To: K.Morgan@iaea.org
- cc: ynir.ietf@gmail.com, ietf-http-wg@w3.org
In message <943AECCF-EE19-4A78-9C39-8C37073F8B53@iaea.org>, K.Morgan@iaea.org writes: >> There can only ever be an issue with the first request, which is >> typically sent before the peers SETTINGS arrive. > >Ok, now I understand. You're advocating for MAX_FRAME_SIZE to be a hard limit >regardless of the default value. What I'm advocating is that A) you can *always* get a 256 byte frame through. and B) that all software SHOULD be configurable to allow 16KB frames. No more, no less. >As I mentioned before, if I understood Jeff correctly, he didn't like this >approach because he couldn't just always use a fixed 16K frame size. And as I analysed in my previous email: In all the cases where Jeff has an opportunity to do that, there is almost certainty that it will always work. The one case I can see where it might fail, is if Jeff tries to access an "intelligent lightbulb" at edison.example.com, after example.com's main websever stuffed his browser with 14 kB of cookies. That's a corner-case I can live with. -- 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 20:39:18 UTC