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> 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).
>