I'm not that interested in talking about lightbulbs. These use cases can appropriately be covered by h2-lowprofile / h2-c, and I've no objection to a 256 byte default and minimum in that context. People mis-configure software all the time. This is a foot-gun. Ex, consider an admin for a deployed service who "tunes" their load-balancer configuration to require smaller frames because they heard that'd improve latency. On Mon, Jul 14, 2014 at 4:47 PM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: > In message <CAEn92TpaQU2zpvcVP=_ > 09iEchqVJonrFzgGUCXRQBSk1Wf84jA@mail.gmail.com>, Johnny Graetting > er writes: > > >Expanding the thought: > > > >If we allow the minimum to be smaller than the default frame size, we will > >get servers who close connections (because they don't want to deal with > >processing the frame, and RST_STREAM isn't an option), and we will get > >clients who repeatedly spin up a new connection and retry the request. > > This is simply not true. > > Why would a client ever send a 16KB HEADERS to a lightbulb which never > has and never will emit a single set-cookies header ? > > Only if a client, point blank, decides to send a request larger than the > server can handle, will there be a problem. > > Please detail the scenarious where that happens ? > > -- > 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 21:02:31 UTC