You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Because sequences of header continuations are required to be contiguous without any interleaving or multiplexing or whatnot... it really does not make sense to limit CONTINUATION frames carrying HTTP headers to 16383 octets, as that needlessly just increases the encoding overhead for continuations. If the END_HEADERS flag is not set, we ought to allow frame sizes up to the maximum allowed (65,535) to eliminate this additional overhead.
The text was updated successfully, but these errors were encountered:
We concluded in Seattle that we didn't want to go with half-measures like this. All frames will be required to be less than 2^14 in size, regardless of the upper layer protocol or frame type.
Because sequences of header continuations are required to be contiguous without any interleaving or multiplexing or whatnot... it really does not make sense to limit CONTINUATION frames carrying HTTP headers to 16383 octets, as that needlessly just increases the encoding overhead for continuations. If the END_HEADERS flag is not set, we ought to allow frame sizes up to the maximum allowed (65,535) to eliminate this additional overhead.
The text was updated successfully, but these errors were encountered: