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

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

From: Johnny Graettinger <jgraettinger@chromium.org>
Date: Mon, 14 Jul 2014 17:02:03 -0400
Message-ID: <CAEn92To2LmVGwqR1uqW_Z45w6ejjpHG8CfmOf6HPN6qnXv0+OQ@mail.gmail.com>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc: "K.Morgan@iaea.org" <K.Morgan@iaea.org>, Yoav Nir <ynir.ietf@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
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

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