Re: Clarification on HTTP/QUIC Unidirectional Streams

[Mikkel Fahnøe Jørgensen <[e-mail]>]

I’m not at all into all the details of HQ/QPACK

but you cannot assume anything about stream identifiers before you see them.

If stream 2 is an obvious control streams, some implementation will make
stream 8 the initial control stream because it will have some idea idea
about forcing the earlier streams open so the peer can do something evil to
them before it even begins sending data. Or they might just do it for the
heck of it to break applications making such assumptions (like ping of
death).

Some implementation could have fewer streams because they are
micro-controllers that do not want to use QPACK compression at all, so
assuming server push on stream 15 would possibly work most of the time at
best.

On 17 October 2018 at 18.23.57, Samuel Hurst ([e-mail]) wrote:

Hi All,


Apologies if this question has been asked before, but I'd just like to
check that my understanding of something is correct and searching back
through the list has not answered my question.

Given that HTTP/QUIC requires each peer in a connection to open a
unidirectional control stream when a connection begins, I think it's
safe to assume that streams 2 and 3 will be the control streams.

Now, a client will make a request on Stream 0, which will include some
QPACK HEADERS, and the odds are that some of those headers will be poked
into the dynamic table (I'm thinking of the User-Agent as a prime
candidate for this).

However, as I understand it, QPACK requires two unidirectional control
streams for the encode (type 'H') and decode (type 'h'). And this is per
encode-decode pair, so there will be another pair of unidirectional
control streams for the encode and decode of the server's response headers.

So in my head, the current state of streams in use is thus:

Stream 0 - Client Request
Stream 2 - Client Control Stream
Stream 3 - Server Control Stream
Stream 6 - Client Headers QPACK Encoder Stream
Stream 7 - Client Headers QPACK Decoder Stream
Stream 10 - Server Headers QPACK Decoder Stream
Stream 11 - Server Headers QPACK Encoder Stream

So, if as part of the request made in stream 0, the server decides to
send a PUSH_PROMISE frame, and then once acknowledged by the client the
server begins the server push immediately, is is a safe assumption to
make that the first server push stream will be on stream 15?

I also don't think there's anything to stop a server from sending a
PUSH_PROMISE frame before it's even sent a HEADERS frame back for the
initial request, so in that case would the server push end up on stream
11, the server headers encoder stream ends up on stream 15 and the
decoder stream stays on stream 10?

I'm just trying to get it into my head exactly what the expected lay of
the land will be during a running HTTP/QUIC session. It's been a while
since I last looked at the QUIC drafts and I'm jumping ahead through
several revisions so it's possible that I've missed something.


Best Regards,
Sam