Re: Striving for Compromise (Consensus?)

> 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. 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

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.

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.

Received on Friday, 11 July 2014 13:18:56 UTC