- From: Jason Greene <jason.greene@redhat.com>
- Date: Mon, 14 Jul 2014 15:45:22 -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:29 PM, Johnny Graettinger <jgraettinger@chromium.org> wrote: > > Ok, now I understand. You're advocating for MAX_FRAME_SIZE to be a hard limit regardless of the default value. The default value of the setting is 16K, but an endpoint can immediately change that on connection open to something lower if it doesn't want to support 16K frames. (This is also true with respect to the hpack table size setting default 4096 value.) > > During the time between connection open and the ack of its settings, the endpoint has to decide to temporarily support frames up to 16K or RST_STREAM with STREAM_REFUSED and hope the client retries. > > I think it's worse than this, because if the client sent a frame larger than the server's MAX_FRAME_SIZE immediately after connection, it was probably a HEADERS frame, and that frame needs to be processed or the compression context is hosed and the connection must be closed. > > Basically the server has the choice of accepting 16K HEADERS frames temporarily, or not talking to that client at all. > > For that reason, I agree with Jeff that the default and minimum should be the same. Just in case it was missed, there was extra low latency use cases discussed a week or two ago where you might want something like a 4k frame. It’s reasonable that a server can actually handle 16+ just fine, but some application/deployment wants to optimize in this area. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat
Received on Monday, 14 July 2014 20:46:01 UTC