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

>
>
> 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.