RE: PUSH_HEADERS frame

[Lucas Pardue <[e-mail]>]

Thanks for the feedback. To be clear, I'm in favor of typed streams but to play devils advocate. 

> Unidirectional streams aren't required to use HTTP/QUIC frames;

QPACK aside, the only examples we have use frames. So the question is: do we think it is in scope to support un-framed STREAM bytes as an HTTP/QUIC extension point?

Back to PUSH_HEADERS, the change is a subtle one. I'd highlight the Header Block, which presently has two bearer frames HEADERS and PUSH_PROMISE. The main difference with push is that the stream ID cannot be used to correlate request and response. So we use a push ID that is framed everywhere *except* the push delivery stream. PUSH_HEADERS is a more honest approach to this quirk (at some small framing inconvenience), everything relevant to the Header Block is bundled together. It acts as a stream reservation mechanism that ties push response data, with request and response headers.  

It doesn't change much: 

Untyped streams (today): push ID + HEADERS + DATA (+ HEADERS)
Typed streams: stream type byte + push ID + HEADERS + DATA (+ HEADERS)
Untyped and framed streams:  PUSH_HEADERS (including push ID) + DATA (+HEADERS)

I could try to make a weak argument that framing helps because you could at least skip over frames if you get their length but not the rest. The current design requires the full push ID to be received before HEADERS and DATA processing.

Lucas