RE: CONTINUATION proposal w/ minimum change

It feels very awkward to make the compressor aware of framing.  Previously, we had said that you take your header set, run it through HPACK, then frame up and send the output using HEADERS/PUSH_PROMISE and CONTINUATION.  Now, the HPACK compressor has to know where the boundary is and change its behavior when it passes that boundary.  I assume that means on the decompression side that the reference set is emitted when the frame boundary is hit, which means the decompressor also needs to be aware of framing.

It gets worse, because a given instruction could cross the boundary.  Whether a header can be indexed or not would depend on whether the header name is already in the table, because the compressor needs to check whether a given header will cause it to cross the boundary.  There's new HPACK text here that will be required, and not very pretty.

By the way, I thought the point of making CONTINUATION only carry literals was to break the requirement that a CONTINUATION MUST immediately follow the incomplete HEADERS/PUSH_PROMISE frame - but I don't see that your pull request does that.  You've brought in new ugliness without getting the return you're looking for.

(Having now read Martin's comments, there's a lot of overlap here.)

From: K.Morgan@iaea.org [mailto:K.Morgan@iaea.org]
Sent: Monday, June 30, 2014 11:00 AM
To: mnot@mnot.net; phk@phk.freebsd.dk
Cc: ietf-http-wg@w3.org
Subject: CONTINUATION proposal w/ minimum change


On Friday,27 June 2014 09:36, mnot@mnot.net<mailto:mnot@mnot.net> wrote:
> Can someone please provide a proposal?



I've incorporated many of the ideas mentioned on the list and in the NYC minutes to create a proposal that (I believe) accomplishes the goals with a minimum amount of change.



Changes:

+ Only the HEADERS and PUSH_PROMISE frames can alter the compression context.

+ CONTINUATION frames can only use hpack literals (optionally Huffman encoded) that don't alter the table.

  - CONTINUATION is flow controlled

  - CONTINUATION has an END_STREAM flag



Benefits:

+ Simplifies CONTINUATION implementation

  - i.e. fixes the nonsensical END_STREAM that doesn't actually end the stream

+ Flow control of CONTINUATION:

  - removes the incentive for implementations to cheat and send large amounts of data in the HEADERS+CONTINUATION jumbo frames

  - may help with certain HOL blocking situations (e.g. connection coalescing)


See pull request here: https://github.com/shearl/http2-spec/commit/5a548553334e35cbba5946d238e9a14c6ba03f7e




This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.