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

[Mike Bishop <[e-mail]>]

MikeBishop approved this pull request.

As we've discussed, I highly approve moving in this direction, and this looks like a solid way of doing it.  Side-note for the transport draft:  In my version of this, I found it useful to subdivide the frame types into three categories:

  - Frames about streams you're sending
  - Frames about streams you're receiving
  - Frames about the connection

...and then be clear anywhere there's a stream reference whether that refers to the sender of the frame's stream or the receiver of the frame's stream.

>  
 ## HTTP Message Exchanges
 
-A client sends an HTTP request on a new pair of QUIC streams. A server sends an
-HTTP response on the same streams as the request.
+A client sends an HTTP request on a new QUIC request stream

Nit:  a "QUIC request stream" implies that request streams are a QUIC-layer concept, not an HTTP-layer one.  Maybe a "new request stream," possibly augmented by some reinforcement that all stream types are QUIC streams?

> @@ -320,39 +449,45 @@ A proxy that supports CONNECT establishes a TCP connection ({{!RFC0793}}) to the
 server identified in the ":authority" pseudo-header field. Once this connection
 is successfully established, the proxy sends a HEADERS frame containing a 2xx
 series status code to the client, as defined in {{!RFC7231}}, Section 4.3.6, on
-the message control stream.
-
-All QUIC STREAM frames on the message data stream correspond to data sent on the
-TCP connection. Any QUIC STREAM frame sent by the client is transmitted by the
-proxy to the TCP server; data received from the TCP server is written to the
-data stream by the proxy. Note that the size and number of TCP segments is not
-guaranteed to map predictably to the size and number of QUIC STREAM frames.
-
-The TCP connection can be closed by either peer. When the client half-closes the
-data stream, the proxy will set the FIN bit on its connection to the TCP server.
-When the proxy receives a packet with the FIN bit set, it will half-close the
-corresponding data stream. TCP connections which remain half-closed in a single
+the response stream.
+
+The data received on the data streams associated with this exchange after the

Might want to be explicit that the request/response streams will need to have HAS_BODY, but I know that's considered vestigial.

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

Agreed.  Any mention of a request having a control stream is leftover from my old terminology -- "on the push stream."

>  
-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
+associated data stream.
 
 
 # HTTP Framing Layer

I think the {{http-framing-layer}} link is intended to point here, but it doesn't have an anchor.

>  The semantics of the Stream Dependency, Weight, and E flag are the same as in
 HTTP/2.
 
 The flags defined are:
 
+  PUSH (0x04):

For consistency, this might be PUSH_PRIORITIZED.  Not stuck on that, though.

>  
   Stream Dependency:
-  : A 32-bit stream identifier for the stream that this stream depends on (see
-    {{priority}} and {!RFC7540}} Section 5.3).
+  : A 32-bit stream identifier for a dependent request.  This contains the
+    stream ID of a request stream when the PUSH flag is clear, or a push ID when
+    the PUSH flag is set.  A request stream ID of 0 indicates a dependency on
+    the root stream. For details of dependencies, see{{priority}} and

Missing a space.

> +   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      Error Code (32)                          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+~~~~~~~~~~
+{: #fig-cancel-request title="CANCEL_REQUEST frame payload"}
+
+The CANCEL_REQUEST frame payload has the following fields:
+
+  Request Stream/Push ID:
+  : A 32-bit stream ID or Push ID that identifies the request.  If the PUSH flag
+    is set, this refers to a Push ID included in a PUSH_PROMISE frame (see
+    {{frame-push-promise}}); if the PUSH flag is cleared, this refers to a
+    request by its stream ID.
+
+  Error Code:
+  : A 32-bit error code indicating why the response is not desired.

Feels a little weird lifting the QUIC error code space into the HTTP frames as well.  Are we sure we need the error code at this level?  "I no longer want it" is already implied by the frame.

> +| Connection Control | n/a  | {{stream-control}}  |
+| Request            | 0x00 | {{stream-request}}  |
+| Response           | 0x01 | {{stream-response}} |
+| Data               | 0x02 | {{stream-data}}     |
+| Push               | 0x03 | {{stream-push}}     |
+{: #stream-type-table title="Stream Types"}
+
+An endpoint MUST terminate the connection with an HTTP_INVALID_STREAM_HEADER
+error if it receives a stream header that uses an unknown or unsupported type.
+
+
+### Stream 1: Connection Control Stream {#stream-control}
+
+Stream 1 is opened by both client and server and is used for the SETTINGS frame
+immediately after the connection opens.  After the SETTINGS frame has been sent,
+this stream is used for PRIORITY frames.

And CANCEL_REQUEST frames

> @@ -648,7 +889,9 @@ entire connection when an error is encountered.  These are referred to as
 [QUIC-TRANSPORT].
 
 HTTP/QUIC requires that only data streams be terminated abruptly.  Terminating a
-message control stream will result in an error of type HTTP_RST_CONTROL_STREAM.
+request, response or push stream will result in an error of type
+HTTP_RST_CONTROL_STREAM.  \[Editor's note: this is clearly busted right now,
+because data streams don't always exist.]

But not so badly, since you can always use CANCEL_REQUEST instead of telling QUIC to reset the stream.

>  
-### half-closed (remote) {#state-hc-remote}
+A stream becomes "closed" at the receiving endpoint when all data is received
+and a STREAM frame with a FIN flag is received or when a RST_STREAM frame is
+received.

It's the associatives that are hard to parse, I think.  ("all data" AND ("STREAM with FIN" OR "RST_STREAM")) versus (("all data" AND "STREAM with FIN") OR "RST_STREAM")

I know which one you mean, and probably everyone in the WG does, but someone reading this document to understand QUIC might get confused.  The "whens" do delineate two cases, but I can understand that being glossed over.

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