Subject: Maximum Frame Size

From: Martin Thomson <[email-masked]>
Date: Mon, 4 Mar 2013 15:20:11 -0800

From: https://github.com/http2/http2-spec/issues/28

HTTP/2.0 requires that implementations support a minimum frame size of
8192 bytes. The draft does not specify how an implementation is
expected to learn that its peer has limited frame sizes other than by
trial and error. Using RST_STREAM causes the error to be discovered
after the problem has been encountered.

It's also not possible to use RST_STREAM to reject a too-large frame
that is not bound to a specific stream.

This could be indicated in the SETTINGS frame.

--

Any objections to adding a new setting for maximum frame size (minimum
value of 8192 bytes).

---

From: Patrick McManus <[email-masked]>
Date: Mon, 4 Mar 2013 21:05:36 -0500

Its very tempting to just get rid of the path discovery signaling and
retry baggage and make the max frame size also the minimum supported
read frame size. When spdy had the max frame size at 31 bits that
wasn't doable - but at 16 bits I think it is. If the group thinks 64KB
is too big but 32KB is not, (for a minimum) then I'd rather reduce the
max frame size than introduce a whole bunch of mechanisms to deal with
pmtud-prime.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 5 Mar 2013 08:49:47 -0800

> max frame size than introduce a whole bunch of mechanisms to deal with

What of it?

1. Reduce the maximum to be the minimum that must be supported.  This
would allow us to remove error cases and negotiation.  Patrick is
suggesting 32K, and of course we can negotiate something else (later).

2. Add settings to signal the maximum size, minimum remains 8192.
Can't send more than 8192 until settings indicate larger.  Remove the
error message.

3. Leave as is with the error message.

The error message does makes things brittle, so removing it would be
good.  A too-large frame that modifies session state will force the
session to be dropped entirely.

---

From: Thomas Maslen <[email-masked]>
Date: Mon, 11 Mar 2013 17:57:40 +0000

If I'm correctly understanding draft-ietf-httpbis-http2-latest:

    An HTTP request may (of course) use any number of DATA frames to send its body (if any)

    But all of the headers for the HTTP request must fit in a single HEADERS+PRIORITY frame

    The frame length is a 16-bit field, so the protocol puts a hard limit of 65535 bytes on the size of any frame (including HEADERS+PRIORITY)

    And, per the "Maximum Frame Size" discussion, implementation limits might be lower, e.g. 32768 or 8192

    And of course ditto all this for the HEADERS frame and HTTP responses

(If I have misunderstood, holler).

I'm not suggesting that the spec should change to let headers straddle multiple frames, and I agree that any HTTP request or response that believes it might need anything like 64K of headers should be looked at askance, but...

I'm wondering whether httpauth will need to take this into account.  (I'm asking here first, rather than on httpauth, to sanity-check my assumptions).

For simple HTTP auth schemes such as Basic and Digest this is a non-issue, because they generate small headers.  But if e.g. you were trying to design an official HTTP auth scheme that used SAML (no, I'm not), then a design that followed the current auth-scheme pattern and tried to put an entire SAML token in an HTTP "Authorization:" header might be problematic.  (On HTTP/1.* it might hit _implementation_ limits, but on the draft HTTP/2.0 it might hit a hard limit in the protocol).  So perhaps httpauth schemes with potentially large tokens should eschew the "WWW-Authenticate" / "Authorization" header pattern and instead make use of the message body.  (That, of course, is what current SAML profiles for HTTP generally resort to doing anyway, but, like forms-based authentication, they end up operating completely outside the official HTTP auth-scheme model).

I know there is at least one httpauth proposal that already moves some tokens out of HTTP headers into a request body, but I'm thinking that if HTTP/2.0 caps the combined size of all headers at 64K (or potentially lower) then httpauth might need to make that a more general principle.

I haven't put any thought into whether authentication is the only case where HTTP header size could be an issue or whether there are other cases where the combined size of HTTP headers could legitimately be large enough to run into HTTP/2.0 limits.  ("Legitimately" rules out silly Accept or User-Agent headers, which I agree should die).

---

From: Martin Thomson <[email-masked]>
Date: Mon, 11 Mar 2013 14:16:56 -0400

Regarding headers spanning frames: It's not in the spec, but it has been
discussed.  I expect this to be added.

It's actually cookies that were the reason cited for having headers that
exceed 64k, not authentication headers.  Though I note that support of this
much header data is an implementation choice, not a requirement of the
spec, so it would be inadvisable to rely on having that much space
available.  (As much - or more so - for HTTP/2.0 as it would be for
HTTP/1.1 today.)  SAML in the headers is probably not a good idea.

On 11 March 2013 13:57, Thomas Maslen <[email-masked]> wrote:

>     The frame length is a 16-bit field, so the protocol puts a hard limit
> of 65535 bytes on the size of any frame (including HEADERS+PRIORITY)
>
> I'm not suggesting that the spec should change to let headers straddle
> multiple frames, and I agree that any HTTP request or response that
> believes it might need anything like 64K of headers should be looked at
> askance, but...
>
> I'm wondering whether httpauth will need to take this into account.  (I'm
> asking here first, rather than on httpauth, to sanity-check my assumptions).
>
> For simple HTTP auth schemes such as Basic and Digest this is a non-issue,
> because they generate small headers.  But if e.g. you were trying to design
> an official HTTP auth scheme that used SAML (no, I'm not), then a design
> that followed the current auth-scheme pattern and tried to put an entire
> SAML token in an HTTP "Authorization:" header might be problematic.  (On
> HTTP/1.* it might hit _implementation_ limits, but on the draft HTTP/2.0 it
> might hit a hard limit in the protocol).  So perhaps httpauth schemes with
> potentially large tokens should eschew the "WWW-Authenticate" /
> "Authorization" header pattern and instead make use of the message body.
>  (That, of course, is what current SAML profiles for HTTP generally resort
> to doing anyway, but, like forms-based authentication, they end up
> operating completely outside the official HTTP auth-scheme model).
>
> I know there is at least one httpauth proposal that already moves some
> tokens out of HTTP headers into a request body, but I'm thinking that if
> HTTP/2.0 caps the combined size of all headers at 64K (or potentially
> lower) then httpauth might need to make that a more general principle.
>
> I haven't put any thought into whether authentication is the only case
> where HTTP header size could be an issue or whether there are other cases
> where the combined size of HTTP headers could legitimately be large enough
> to run into HTTP/2.0 limits.  ("Legitimately" rules out silly Accept or
> User-Agent headers, which I agree should die).
>

---

From: James M Snell <[email-masked]>
Date: Mon, 11 Mar 2013 11:40:39 -0700

If by "probably not a good idea" you mean "not a good idea at all"  then
def +1. For the most part I think we need to at least be prepared for
headers to span multiple frames but I don't see that being anywhere close
to "best practice behavior" unless the headers in subsequent frames serve a
distinct application purpose (e.g. Separating content headers from control
headers etc)
 On Mar 11, 2013 11:19 AM, "Martin Thomson" <[email-masked]>
wrote:

>> For simple HTTP auth schemes such as Basic and Digest this is a
>> non-issue, because they generate small headers.  But if e.g. you were
>> trying to design an official HTTP auth scheme that used SAML (no, I'm not),
>> then a design that followed the current auth-scheme pattern and tried to
>> put an entire SAML token in an HTTP "Authorization:" header might be
>> problematic.  (On HTTP/1.* it might hit _implementation_ limits, but on the
>> draft HTTP/2.0 it might hit a hard limit in the protocol).  So perhaps
>> httpauth schemes with potentially large tokens should eschew the
>> "WWW-Authenticate" / "Authorization" header pattern and instead make use of
>> the message body.  (That, of course, is what current SAML profiles for HTTP
>> generally resort to doing anyway, but, like forms-based authentication,
>> they end up operating completely outside the official HTTP auth-scheme
>> model).
>>

---

From: Thomas Maslen <[email-masked]>
Date: Mon, 11 Mar 2013 19:23:33 +0000

On 11 March 2013 11:19 AM, "Martin Thomson" <[email-masked]> wrote:
> Regarding headers spanning frames: It's not in the spec, but it has been discussed.  I expect this to be added.
>
> It's actually cookies that were the reason cited for having headers that exceed 64k, not authentication headers.  Though I note that support of this much header data is an implementation choice, not a requirement of the spec, so it would be inadvisable to rely on having that much space available [...]

Thanks.  I agree (and perhaps HTTP/2.0 should _not_ add support for headers spanning frames, in order to force the issue -- although then 2.0 would have a hard protocol limit where 1.1 only had implementation limits).

> [...] SAML in the headers is probably not a good idea.

Yup.  Ditto for any other auth scheme that may have large enough tokens to be problematic.  I think this means that auth schemes with potentially large tokens should not rely too much on the "Authorization:" header and should instead somehow make use of the request body.  (If, of course, there isn't a way to put the tokens on a forced diet that's guaranteed to get all tokens down to a size that's guaranteed not to be problematic).

________________________________
From: Martin Thomson [[email-masked]]
Sent: Monday, March 11, 2013 11:16
To: Thomas Maslen
Cc: Patrick McManus; HTTP Working Group
Subject: Re: Maximum Frame Size

Regarding headers spanning frames: It's not in the spec, but it has been discussed.  I expect this to be added.

It's actually cookies that were the reason cited for having headers that exceed 64k, not authentication headers.  Though I note that support of this much header data is an implementation choice, not a requirement of the spec, so it would be inadvisable to rely on having that much space available.  (As much - or more so - for HTTP/2.0 as it would be for HTTP/1.1 today.)  SAML in the headers is probably not a good idea.

On 11 March 2013 13:57, Thomas Maslen <[email-masked]<mailto:[email-masked]>> wrote:
If I'm correctly understanding draft-ietf-httpbis-http2-latest: