Re: [quicwg/base-drafts] Allow not creating QPACK codec streams (#2529)

[Mike Bishop <[e-mail]>]

MikeBishop commented on this pull request.



>  HTTP/3 endpoints contain a QPACK encoder and decoder. Each endpoint MUST
-initiate a single encoder stream and decoder stream. Receipt of a second
-instance of either stream type be MUST treated as a connection error of type
+initiate at most one encoder stream and one decoder stream. Receipt of a second

> Maybe swap the order to "one decoder stream and at most one encoder stream" to make it less likely to be misread as "at most one encoder stream and at most one decoder stream".

Perhaps this manifests a difference of opinion, but that's exactly how I read this text, and what I think it should say.  An implementation could defer creating both the decoder stream (because the peer hasn't yet sent anything that needs acknowledgement) and the encoder stream (because it doesn't intend to send anything on the dynamic table).

>  HTTP_WRONG_STREAM_COUNT. These streams MUST NOT be closed. Closure of either
 unidirectional stream type MUST be treated as a connection error of type
 HTTP_CLOSED_CRITICAL_STREAM.
 
+An endpoint MAY avoid creating its own encoder stream if the maximum size of
+the dynamic table permitted by the peer is zero.
+
+An endpoint MAY avoid creating its own decoder stream if the maximum size of
+its own dynamic table is zero.
+
+An endpoint MUST allow its peer to create both encoder and decoder streams

> I think most implementations will take closed streams into account to know when to issue more uni stream credit. In the case of servers, there's never a need to increase it in vanilla HTTP/3. Clients need only increase it when they want more pushes (or grease, or extensions, etc).

Once the three basic streams are opened, servers never need to increase the number of streams, true.  However, the server still needs to keep giving credit as streams close until those three are opened at least.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2529#discussion_r279883054