Re: Maximum Frame Size

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