Re: Striving for Compromise (Consensus?)

On 12/07/2014 1:18 a.m., Jeff Pinner 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. 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


Er. So up-front knowledge of information X utilizing 8 bytes of protocol
header is important for reducing 1-bit of boolean state.

Why is information X more important than the size of the compressed
headers which is to follow? so important that its worth burning overhead
bandwidth at a ratio of 8:1 but frame size is not worth expanding at a
ratio of 2:65535 or better?

I do agree that types are important info to have up front. But size
being known up front is equally important, and has a far better
cost/benefit ratio.

> 
> 2) Unlike DATA frames, HEADERS contain content that is not arbitrarily
> divisible which makes flow controlling them difficult
> "out-of-the-box."

Thank you. You have given solid reason here for dropping CONTINUATION.
Which is h2-13 splitting of HEADERS content over multiple frames.

Amos

Received on Saturday, 12 July 2014 04:32:24 UTC