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

On 14 Jul 2014, at 22:29, "jgraettinger@chromium.org<mailto:jgraettinger@chromium.org>" <jgraettinger@chromium.org<mailto: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.

I opened this very issue a few weeks ago.  I was told that if you set the table size to 0, you can rst_stream, but you don't have to close the connection. When the client retries it should have already seen your new settings with table_size=0 and max_frame=256, so all should be well.






This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

Received on Monday, 14 July 2014 21:30:37 UTC