- From: Jason Greene <jason.greene@redhat.com>
- Date: Mon, 14 Jul 2014 15:58:40 -0500
- To: Johnny Graettinger <jgraettinger@chromium.org>
- 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>
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