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

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 :)


On Mon, Jul 14, 2014 at 4: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.
>