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

[Lucas Pardue <[e-mail]>]

LPardue commented on this pull request.



>  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'm not sure that's such a big deal. If you planned to use the dynamic table, but wasted your stream on grease instead of an encoder stream, then you can't use the table.

The problem is that the sender has no intention of creating an encoder stream but the receiver doesn't know that. If the receiver is eager to use QPACK, it keeps giving back a stream credit for every unidirectional stream that is "wasted" before creating the encoder stream. Even if it didn't give back credit immediately and did let the max uni stream limit be hit, there is no guarantee that the next time the receiver gives credit (say for a push promise) that then it wouldn't spontaneously be used for QPACK. 


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