- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Mon, 14 Jul 2014 15:21:44 +0000
- To: Jeff Pinner <jpinner@twitter.com>
- cc: "K.Morgan@iaea.org" <K.Morgan@iaea.org>, ynir.ietf@gmail.com, HTTP Working Group <ietf-http-wg@w3.org>
In message <CA+pLO_hTyehQXNdk5YNTmb_fTx5WAUnEigoBn+U97PSPeUDpLw@mail.gmail.com>, Jeff Pinner writ es: >With a 10 byte header (to fit a 32-bit length field), setting the >MAX_FRAME_SIZE to 256 is almost a 4% !! overhead in the transmitted >bytes just for framing the data. > >I can't imagine I would do anything other than send a GO_AWAY and >close the connection. And that's fine, if you're sure you'll never download new firmware to "intelligent lightbulbs" etc. >Can we just keep the minimum frame size the same as today and use >settings to increase only? Because that would force anybody with a small microcontroller to be non-compliant for no good reason. >The argument against doesn't make sense to me, embedded clients >already have to deal with a 16-bit IP length field so the idea that >they can't handle a 14-bit HTTP length field seems absurd. They typically only have to deal with a single packet of their chosen transport. The rest can be held as state. Please understand that the 256 is there to avoid people implementing smaller limits, not larger limits. -- 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 15:22:11 UTC