Re: [quicwg/base-drafts] Unidirectional Streams (#643)

[Lucas Pardue <[e-mail]>]

LPardue commented on this pull request.



>  
-##  Stream 1: Connection Control Stream
+~~~~~
+ 0                   1                   2                   3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+
+|   Type (8)    |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                         Push ID (32)                          |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+~~~~~

It seems this diagram is missing the 16-bit index value described in the text.

> +The stream header for a response stream contains the type octet, which is set to
+0x01, and the stream ID of the request stream that this response is for as a
+32-bit value.
+
+~~~~~
+ 0                   1                   2                   3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+
+|   Type (8)    |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                        Stream ID (32)                         |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+~~~~~
+
+After the stream header, response streams contain a sequence of frames (see
+{{http-framing-layer}}).

Not sure where the `http-framing-layer` link is supposed to take us to.

>  
 HTTP/QUIC uses the priority scheme described in {{!RFC7540}} Section 5.3. In
-this priority scheme, a given stream can be designated as dependent upon another
-stream, which expresses the preference that the latter stream (the "parent"
-stream) be allocated resources before the former stream (the "dependent"
-stream). Taken together, the dependencies across all streams in a connection
-form a dependency tree. The structure of the dependency tree changes as PRIORITY
-frames add, remove, or change the dependency links between streams.
+this priority scheme, a given request can be designated as dependent upon
+another request, which expresses the preference that the latter stream (the
+"parent" request) be allocated resources before the former stream (the
+"dependent" request). Taken together, the dependencies across all request in a

nit: the dependencies across all request**s**

>  
 HTTP/QUIC uses the priority scheme described in {{!RFC7540}} Section 5.3. In
-this priority scheme, a given stream can be designated as dependent upon another
-stream, which expresses the preference that the latter stream (the "parent"
-stream) be allocated resources before the former stream (the "dependent"
-stream). Taken together, the dependencies across all streams in a connection
-form a dependency tree. The structure of the dependency tree changes as PRIORITY
-frames add, remove, or change the dependency links between streams.
+this priority scheme, a given request can be designated as dependent upon
+another request, which expresses the preference that the latter stream (the
+"parent" request) be allocated resources before the former stream (the
+"dependent" request). Taken together, the dependencies across all request in a
+connection form a dependency tree. The structure of the dependency tree changes
+as PRIORITY frames add, remove, or change the dependency links between request.

nit: the dependency links between request**s**

> -
-The data stream MUST be half-closed immediately after the transfer of the body.
-If the message does not contain a body, the corresponding data stream MUST still
-be half-closed without transferring any data. The "chunked" transfer encoding
-defined in Section 4.1 of {{!RFC7230}} MUST NOT be used.
+response may contain zero or more header blocks on the response stream
+containing the message headers of informational (1xx) HTTP responses (see
+{{!RFC7230}}, Section 3.2 and {{!RFC7231}}, Section 6.2).
+
+A message that contains a payload body includes a HAS_BODY frame immediately
+after the first header block.  This indicates that another stream will include
+the payload body.  A data stream is opened to carry the payload body.  The data
+stream MUST be closed immediately after sending the body.  If the message does
+not contain a body, a data stream MUST NOT be opened and the HAS_BODY message
+MUST NOT be sent.  The "chunked" transfer encoding defined in Section 4.1 of
+{{!RFC7230}} MUST NOT be used.
 
 Trailing header fields are carried in an additional header block on the message
 control stream. Such a header block is a sequence of HEADERS frames with End

Sending trailing header fields on the control stream seems like a hangover from earlier design.

>  
-The server push response is conveyed in the same way as a non-server-push
-response, with response headers and (if present) trailers carried by HEADERS
-frames sent on the control stream, and response body (if any) sent via the
-corresponding data stream.
+The server push response is conveyed on a push stream.  Aside from the stream
+header, which identifies the response stream and PUSH_PROMISE frame, a push
+stream is identical to a regular response stream ({{stream-response}}), with
+response headers and (if present) trailers carried by HEADERS frames sent on the
+control stream, and response body (if any) indicated with a HAS_BODY frame and

My reading of the design is that trailing header fields would be carried on the push stream, not the control stream.

> @@ -401,6 +547,14 @@ All frames have the following format:
 
 ## Frame Definitions {#frames}
 
+### HAS_BODY {#frame-has-body}
+
+The HAS_BODY frame indicates that the HTTP message contains a payload body.  It

Is it missing a frame type?

> @@ -712,6 +936,21 @@ HTTP_MULTIPLE_SETTINGS (0x10):
 HTTP_RST_CONTROL_STREAM (0x11):
 : A message control stream closed abruptly.
 
+HTTP_INVALID_STREAM_HEADER (0x12):
+: A stream header contained an unknown type or referenced an invalid stream.
+
+HTTP_UNMATCHED_RESPONSE (0x13):
+: A response stream referenced an invalid stream.
+
+HTTP_UNMATCHED_DATA (0x14):
+: A data stream referenced an invalid stream.
+
+HTTP_UNMATCHED_PUSH (0x15):
+: A push stream referenced an server push request.

nit: **a** server push request

> @@ -758,8 +997,8 @@ QUIC simply by replacing Stream 0 in HTTP/2 with Stream 1 in HTTP/QUIC.
 Below is a listing of how each HTTP/2 frame type is mapped:
 
 DATA (0x0):
-: Instead of DATA frames, HTTP/QUIC uses a separate data stream.  See
-  {{stream-mapping}}.
+: Instead of DATA frames, HTTP/QUIC uses a separate data stream.  The code point
+  for DATA frames is used for the HAS_BODY frame. See {{frame-has-body}}.

Maybe this answers my earlier question about HAS_BODY type?

-- 
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/643#pullrequestreview-45396112