RE: Maximum Frame Size

On 11 March 2013 11:19 AM, "Martin Thomson" <martin.thomson@gmail.com> 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 [martin.thomson@gmail.com]
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 <Thomas.Maslen@quest.com<mailto:Thomas.Maslen@quest.com>> wrote:
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).