Re: Striving for Compromise (Consensus?)

On 11 Jul 2014, at 15:22, "jpinner@twitter.com" <jpinner@twitter.com> wrote:

>> I'm with Greg, though, what is the reason for needing a distinction between HEADERS and DATA frames?  The same thing could easily be accomplished with just DATA frames logically divided into a http request of "headers data [trailers]" just by the END_SEGMENT flag.
>
> The distinction is due to two things:
>
> 1) Having different opcodes for DATA and HEADERS frames allows us to
> know up front if the frame needs to be decompressed by HPACK.
>
> Using END_SEGMENT requires us to remember which segment in the HTTP
> message is currently being received to decode the data properly.

Once again, thanks for taking the time to answer my questions.
In /1 you have to keep track of where you're parsing (eg headers come before "\r\n\r\n"). But, if I infer correctly from your response, the problem is that you have to decompress the headers frame before passing it to the application layer because of the shared compression state. Curse that stateful compression...


> It
> also prevents experimenting with the type of inter-message HEADERS
> frames that some people wanted (streaming checksums and the like) that
> are currently permitted to be sent but have no "semantic" mapping to
> HTTP/1.1

I'm all for this, but I've said this before, and I'll say it again. Re-using HEADERS frames for this purpose is confusing. Are they hpack encoded? What does it mean if you get an intra-message HEADERS frame and END_HEADERS is set? Is END_STREAM allowed?

Why not just add a simple METADATA frame and be done with it?


>
> 2) Unlike DATA frames, HEADERS contain content that is not arbitrarily
> divisible which makes flow controlling them difficult
> "out-of-the-box."
>
> For example, if I want to send 2 bytes of DATA on a stream that has a
> window_size of 1, I can break it up and send a single byte in the
> frame. The receiver then knows the window_size has gone to 0 and that
> will cause the stream to stall.
>
> If we try to flow control HEADERS, we run into a situation where we
> could deadlock: if I compress a header to a 2 byte HPACK opcode, and I
> want to send it on a stream with that has a window_size of 1, I can't.
> I could try to split it into two frames using CONTINUATIONS and send
> one, but now the HPACK opcode crosses a frame boundary where the
> second frame needs an RTT to be sent, stalling all header processing.

Couldn't you solve this scenario by sending 2 bytes of padding to drain the window? Of course you wouldn't want to compress and then have to rewind - so I wouldn't ever compress unless I knew the worst case (literal w/o Huffman) could fit in the remaining window.

-Keith


>
> In order to flow control HEADERS we'd have to add an expanded BLOCKED
> frame that lets the sender inform the receiver that it is blocked on a
> stream with a non-0 window_size and include how many extra bytes the
> window_size needs to be increased in order to fit the frame.
>
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.

Received on Saturday, 12 July 2014 21:34:44 UTC