Re: Clarification on HTTP/QUIC Unidirectional Streams

[Samuel Hurst <[e-mail]>]

On 17/10/2018 18:42, Mikkel Fahnøe Jørgensen wrote:
> 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).

Oh absolutely, but I was more thinking of an example flow with a client 
behaving in an at least somewhat predictable and not malicious manner. 
I'm mostly trying to sort out in my head how the QPACK encoder/decoder 
streams work together, apologies if that wasn't as clear as it could've 
been.

I'm fully aware that a client could open as many unidirectional streams 
as it likes and as long as it doesn't do anything else on those streams 
before starting a control stream somewhere.

And if something opens a control stream on Stream 8, shouldn't that be a 
protocol error, as stream 8 is not a unidirectional stream?

> 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.

There's nothing in the specs that specifies when the QPACK 
encoder/decoder streams are opened, so I was going on the assumption 
that they are only opened when a client wants to use the dynamic table. 
If a client only wants to send literal headers or reference in the 
static table, or if the table size is set to zero in the SETTINGS frame, 
I'd assume the QPACK streams will not be opened. In which case, the 
first server push could be stream 7.

-Sam