Subject: [quicwg/base-drafts] CONTINUATION/END_HEADERS-die-die-die? (#76)

From: Mike Bishop <[email-masked]>
Date: Thu, 08 Dec 2016 10:26:10 -0800

In HTTP/2, the CONTINUATION frame was (much loathed)[https://github.com/http2/http2-spec/pull/548], but ultimately deemed a necessary evil since there are some truly, ridiculously large headers out there (*\*cough\** Kerberos *\*cough\**).  The current HTTP/QUIC draft allows a frame to be 64KB long before decoding the HPACK.  Is this large enough?  That was the boundary we'd said it would take in HTTP/2 to require a single frame.

If not, the current draft uses the END_HEADERS bit to indicate that another HEADERS frame will follow, which is effectively the same as CONTINUATION.  The same is not currently defined for PUSH_PROMISE (which really ought to be much smaller).

If so, could we drop the END_HEADERS thing entirely and say that HPACK-bearing frames are fully self-contained?  It would simplify a lot of client mechanics.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/76

---

From: Patrick McManus <[email-masked]>
Date: Thu, 08 Dec 2016 22:24:28 -0800

seems like something the browsers could collect data on for their current
h2 impls.. I don't currently have it, but if people are willing to put a
pin in this for a while I can add it.. maybe chrome too?

On Thu, Dec 8, 2016 at 8:26 AM, Mike Bishop <[email-masked]>
wrote:

> In HTTP/2, the CONTINUATION frame was (much loathed)[https://github.com/
> http2/http2-spec/pull/548], but ultimately deemed a necessary evil since
> there are some truly, ridiculously large headers out there (**cough**
> Kerberos **cough**). The current HTTP/QUIC draft allows a frame to be
> 64KB long before decoding the HPACK. Is this large enough? That was the
> boundary we'd said it would take in HTTP/2 to require a single frame.
>
> If not, the current draft uses the END_HEADERS bit to indicate that
> another HEADERS frame will follow, which is effectively the same as
> CONTINUATION. The same is not currently defined for PUSH_PROMISE (which
> really ought to be much smaller).
>
> If so, could we drop the END_HEADERS thing entirely and say that
> HPACK-bearing frames are fully self-contained? It would simplify a lot of
> client mechanics.
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/76>, or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AAP5s63TQRhQ8MAPmWUICDH6gRXM20igks5rGEvCgaJpZM4LIIca>
> .
>

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/76#issuecomment-265943121

---

From: Mike Bishop <[email-masked]>
Date: Fri, 09 Dec 2016 11:27:42 -0800

Can't hurt.  The problem is we're really looking for outliers here -- not just the norm, but the largest header set anyone's ever had to deal with, and that's probably coming from something pretty specialized.

For our case, our mega-single-header scenario is carrying Kerberos tokens, which we've seen as large as 48KB, which then get Base64-encoded to 64KB.  (Huffman hopefully helps recover some of this, though.)  Looking a little, I see our [maximum configurable limits](https://support.microsoft.com/en-us/kb/820129) are 64KB per header field and **16MB** for the total of all headers.

That may be our answer, unfortunately -- if we want to continue being able to support 16MB of headers (ick), we'll need larger than a 64KB HEADERS frame *in extremis*.  However, Kerberos isn't yet supported over a multiplexed HTTP mapping, so this may be hypothetical for the time being.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/76#issuecomment-266100291

---

From: Mike Bishop <[email-masked]>
Date: Sat, 17 Dec 2016 14:04:18 -0800

Related question:  Repeated HEADERS with an END_HEADER_BLOCK flag, or keep CONTINUATION?  IIRC, the reason we used CONTINUATION was because the subsequent blocks weren't allowed to contain the PRIORITY section which no longer exists.  The counter being present only on the first block might argue for bringing back CONTINUATION, but I'm hopeful we can get rid of that before we ship the spec.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/76#issuecomment-267790104

---

From: Martin Thomson <[email-masked]>
Date: Sun, 18 Dec 2016 00:20:16 -0800

Well, the question is academic if the headers frame can be arbitrarily/sufficiently large.  I would rather not conclude until we decide that question and the QPACK issue as well.  That suggests that we might want to track that as a separate issue.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/76#issuecomment-267809236