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

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

From: Jason Greene <jason.greene@redhat.com>
Date: Mon, 14 Jul 2014 15:58:40 -0500
Cc: "K.Morgan@iaea.org" <K.Morgan@iaea.org>, Poul-Henning Kamp <phk@phk.freebsd.dk>, ynir.ietf@gmail.com, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <9B18840B-CFF2-4C6B-981D-41B409119CB6@redhat.com>
To: Johnny Graettinger <jgraettinger@chromium.org>

On Jul 14, 2014, at 3:42 PM, Johnny Graettinger <jgraettinger@chromium.org> wrote:

> 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. They'll appear to inter-op correctly most of the time, so long as the client's actual headers are within the server's frame limit. When they don't work, though, we'll see lots of mysterious infinite retry loops :)

I have wondered what the exact behavior should be for the case of hpack table size < 4k when this type of edge case occurs. The server can send SETTINGS_TIMEOUT, but that doesnít really seem appropriate, since it just means it didnít get the ACK fast enough, not hey donít send anything before you read my settings. Perhaps we need a RETRY_USING_SETTINGS or something like that.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
Received on Monday, 14 July 2014 20:59:18 UTC

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