RE: PUSH_HEADERS frame

[Lucas Pardue <[e-mail]>]

Well, I only partially buy the simplicity from reusing HEADERS. The client has juggling to do to parse push ID in order to correlate the response with request - I'd argue whether it is done inside or outside the frame equally trivial.

Anecdotally, when explaning HTTP/QUIC server push to an audience not tracking WG progress so closely, it has struck people as quite a departure from H2 and GQUIC (for the better I might add). FWIW I think typed streams would make communication easier, as it makes the capability more conspicuous.

Lucas
________________________________________
From: Martin Thomson [[e-mail]]
Sent: 21 June 2018 00:51
To: Mike Bishop
Cc: Lucas Pardue; Roberto Peon; QUIC WG
Subject: Re: PUSH_HEADERS frame

I agree with Mike.  FWIW, implementing push is trivial as a result of
it using the same framing as requests and responses; I would be
opposed to changing that.
On Thu, Jun 21, 2018 at 4:58 AM Mike Bishop <[e-mail]> wrote:
>
> 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