W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

Re: Maximum Frame Size

From: James M Snell <jasnell@gmail.com>
Date: Mon, 11 Mar 2013 11:40:39 -0700
Message-ID: <CABP7RbeL9QkdbKddzYukJHVpLbb8K+RWcQt-m7LSA7=ukQYMLw@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: ietf-http-wg@w3.org, Thomas Maslen <Thomas.Maslen@quest.com>, Patrick McManus <pmcmanus@mozilla.com>
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>

> 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
>>     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 18:41:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:10 UTC