RE: Design Issue: Frame Size Items

The reason this is a problem is that, if I accidentally violate your max frame size, you reset my stream.  At best, I resend the content in smaller frames; if that frame had a header block, though, we've corrupted the compression context and have to drop and restart the connection.  If that frame wasn't stream-related, there's no stream to reset, and we still have to drop and restart the connection.

So now I have to track the size of the frame you didn't like, and keep that as my new best guess at your maximum.  But it's not actually your maximum, it's a number I know is past your maximum.  So I may hit your actual maximum again with a future frame, hitting this problem over and over and asymptotically approaching your real maximum.

Better to know up front.  We can specify an initial (large) value and peers only need to change it if they need to restrict to a smaller value.  Of course, the client could exceed the server's limits with a huge HEADERS+PRIORITY before seeing the server's SETTINGS frame....

-----Original Message-----
From: James M Snell [mailto:jasnell@gmail.com] 
Sent: Tuesday, May 7, 2013 8:20 AM
To: ietf-http-wg@w3.org
Subject: Design Issue: Frame Size Items

1. There is an existing ed note in the draft indicating that we currently do not have any way of specifying the maximum frame size.
There are several possibilities:

  a. We decide we don't need to report a maximum frame size.
  b. We introduce a MAX_FRAME_SIZE setting for the SETTINGS frame.
  c. We add a headers block to the RST_FRAME and GOAWAY frames ;-) ..

  I think I prefer option (a) but (b) works too.

2. In the current draft we say that all implementations MUST be capable of supporting frames up to 8192 octets in length. We don't say, however, whether that size includes the 8-byte header or is that just payload octets?

- James

Received on Tuesday, 7 May 2013 18:07:17 UTC