Re: [quicwg/base-drafts] create codec streams only when necessary (#2090)

[Mike Bishop <[e-mail]>]

MikeBishop approved this pull request.

I'm of split mind on this.  I see the benefit for small implementations, though I suspect that benefit is marginal.  

At first glance, this seems like an implementation can no longer create the streams and then hand them to the encoder/decoder implementations -- the stream has to get lazily initialized, not sending the type byte until the codec is ready to send something further.  This probably also means not claiming a Stream ID either (use in order!), which means that the Stream ID allotment might not be there when you do go to send something.  Or, if you do claim the stream and then use a higher-numbered unidirectional stream, this one gets implicitly opened but the type byte is never sent, so it sits in limbo at the receiver.

However, I think the key here is in waiting until SETTINGS is received.  The new SETTINGS text says that you can operate in constrained mode (no dynamic table) before receiving SETTINGS.  That would mean that the call to the codec providing the streams and the table size is a step after the encoder and decoder are already operational, rather than start-up initialization.  This change, then, is simply a check in that call to determine whether to pass streams to the codec at all.

Seen from that perspective, this seems more palatable.

>  Receipt of a second instance of either stream type MUST be treated as a
 connection error of HTTP_WRONG_STREAM_COUNT.  Closure of either unidirectional
 stream MUST be treated as a connection error of type
 HTTP_CLOSED_CRITICAL_STREAM.
 
+An endpoint MUST NOT create an encoder stream if the maximum size of the
+dynamic table permitted by the peer is zero.  Observation of a peer-initiated
+encoder stream when the value is zero MUST be treated as a connection error of

"without sending a non-zero value for `SETTINGS_HEADER_TABLE_SIZE`"

>  Receipt of a second instance of either stream type MUST be treated as a
 connection error of HTTP_WRONG_STREAM_COUNT.  Closure of either unidirectional
 stream MUST be treated as a connection error of type
 HTTP_CLOSED_CRITICAL_STREAM.
 
+An endpoint MUST NOT create an encoder stream if the maximum size of the
+dynamic table permitted by the peer is zero.  Observation of a peer-initiated
+encoder stream when the value is zero MUST be treated as a connection error of
+type HTTP_QPACK_ENCODER_STREAM_ERROR.
+
+An endpoint MUST NOT create a decoder stream until the peer opens an encoder
+stream.  Observation of a peer-initiated decoder stream that lacks the
+corresponding encoder stream MUST be treated as a connection error of type

"when no encoder stream has been initiated locally"

-- 
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/2090#pullrequestreview-181408669