RE: PUSH_HEADERS frame

[Mike Bishop <[e-mail]>]

Philosophically, I'd go a step further and say that, as in the PR, the semantics of the stream are entirely determined by the type byte.  Any internal divisions of regions within the bytestream are as needed by that type and defined by it.  Some, like the QPACK stream, won't actually need divided regions.

The fact that push streams and control streams subdivide their regions using frames from the same type space as request streams is somewhere between a convenience due to push's similarity to things we already have (responses) and a historical legacy of H2.  There's no reason they would need to do so; there's just also no real reason to change.

-----Original Message-----
From: Lucas Pardue [mailto:[e-mail]] 
Sent: Wednesday, June 20, 2018 11:28 AM
To: Mike Bishop <[e-mail]>; Martin Thomson <[e-mail]>; Roberto Peon <[e-mail]>
Cc: QUIC WG <[e-mail]>
Subject: RE: PUSH_HEADERS frame

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