- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Wed, 25 Jun 2014 19:12:43 +0000
- To: K.Morgan@iaea.org
- cc: gregw@intalio.com, mnot@mnot.net, w@1wt.eu, ietf-http-wg@w3.org, duerst@it.aoyama.ac.jp
In message <0356EBBE092D394F9291DA01E8D28EC201186F24D7@sem002pd>, K.Morgan@iaea
.org writes:
>2. SETTINGS are only 32 bits. Depending on your answer to #1, there would
>need to be two or three SETTINGS (low, high, high-high) to capture the full
>range of possible MAX frame size values. Perhaps a better option would be
>to have the setting defined as a multiple of 16K chunks (minus one?).
So this is a weak spot, because SETTINGS is only for the connection.
Ideally you should be able to bang up the frame size for a single
stream (as in: Client sess "Content-Length: ALOT" and tells server
to "just get it overhere ASAP" with a big frame size for that stream.
However, that's probably overthinking things, since connections where
that would help are very likely to have only one stream to begin with.
(If we later allow SETTINGS per stream, we get this for free.)
With a little tweak SETTINGS could be 56 bits, that's the cleanest
solution, especially for future settings we havn't thought about.
If we want to fit inside 32 bits, we can either limit the framesize
to 4GB, which is probably safe, but robs us the ability to send
huge objects as a single DATA frame.
Another way could be to go "scientific":
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier (8)|
+---------------+-------------------------------+---------------+
| Value (24) + Shift (8) |
+-----------------------------------------------+---------------+
Where the max framesize will then be
Value * 2^(Shift) /* (Value << Shift) in C syntax. */
I prefer making SETTINGS 56 bits.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
Received on Wednesday, 25 June 2014 19:13:06 UTC