RE: Maximum Frame Size

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

Received on Monday, 11 March 2013 17:58:09 UTC