Subject: [quicwg/base-drafts] Import most H2 references (#3407)

From: Mike Bishop <[email-masked]>
Date: Tue, 04 Feb 2020 02:38:06 -0800

The intent is that RFC7540 is an informative reference after this PR and #3352.  Goes a long way toward fixing #3264.

It&#39;s intended to be purely editorial, despite the normative language -- these are requirements which were previously incorporated by reference to RFC 7540 and are now explicitly stated in the document.  However, some of the imported requirements didn&#39;t have specifications about what you do if they&#39;re not met, so I did have to add that text.

The Security Considerations of RFC7540 are substantial.  If we think it&#39;s worth not simply referencing 7540 for that discussion, that deserves its own PR.  Opinions on the value of that are welcome here, however.

@royfielding, GitHub doesn&#39;t let me directly request your review, but I would appreciate it.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/3407

-- Commit Summary --

  * Import most H2 references

-- File Changes --

    M draft-ietf-quic-http.md (102)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/3407.patch
https://github.com/quicwg/base-drafts/pull/3407.diff

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

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 05 Feb 2020 06:50:57 -0800

royfielding commented on this pull request.

> @@ -552,10 +569,18 @@ an entire HTTP connection into a tunnel to a remote host. In HTTP/2, the CONNECT
 method is used to establish a tunnel over a single HTTP/2 stream to a remote
 host for similar purposes.
 
-A CONNECT request in HTTP/3 functions in the same manner as in HTTP/2. The
-request MUST be formatted as described in Section 8.3 of {{!HTTP2}}. A CONNECT
-request that does not conform to these restrictions is malformed (see
-{{malformed}}). The request stream MUST NOT be closed at the end of the request.
+A CONNECT request in HTTP/3 functions in the same manner as in HTTP/2.

I think it would be simpler for a reader to assume everything functions in the same manner as HTTP/2, and only note when it doesn't.  Likewise, this document defines HTTP/3, so no need to repeat that either. IOW, an editorial suggestion I would go with:

  `A CONNECT request MUST be constructed as follows:`

just to make it much easier to read.

Actually, I would begin the paragraph with a one-line description of the method from http-core Semantics, with a normative reference, like

`The CONNECT method requests that the recipient establish a tunnel to the destination origin server identified by the request-target (Section X.x of [ref:Semantics]).  A CONNECT request MUST be constructed as follows:`

-- 
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/3407#pullrequestreview-353775194

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 05 Feb 2020 06:54:25 -0800

> @@ -598,11 +623,11 @@ HTTP/3 does not support the HTTP Upgrade mechanism (Section 6.7 of [RFC7230]) or
 
 ## Server Push
 
-Server push is an interaction mode introduced in HTTP/2 {{!HTTP2}} which permits
+Server push is an interaction mode introduced in HTTP/2 {{?HTTP2}} which permits

Likewise, 

`Server push is an interaction mode that allows a server to push ...`

the history is not important (and also described at the end of para).

-- 
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/3407#pullrequestreview-353778087

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 05 Feb 2020 07:02:07 -0800

LPardue commented on this pull request.

>  Prior to making requests for an origin whose scheme is not "https," the client
 MUST ensure the server is willing to serve that scheme.  If the client intends
 to make requests for an origin whose scheme is "http", this means that it MUST
 obtain a valid `http-opportunistic` response for the origin as described in
 {{!RFC8164}} prior to making any such requests.  Other schemes might define
 other mechanisms.
 
+Servers are encouraged to maintain open connections for as long as possible but
+are permitted to terminate idle connections if necessary.  When either endpoint
+chooses to close the QUIC connection, the terminating endpoint SHOULD first send
+a GOAWAY frame ({{connection-shutdown}}) so that both endpoints can reliably
+determine whether previously sent frames have been processed and gracefully
+complete or terminate any necessary remaining tasks.

The text here requires both endpoints can send GOAWAY, which I think means a dependency on https://github.com/quicwg/base-drafts/pull/3129

-- 
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/3407#pullrequestreview-353784581

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 05 Feb 2020 07:03:01 -0800

> @@ -659,6 +704,15 @@ CANCEL_PUSH frame, the client can abort reading the stream with an error code of
 H3_REQUEST_CANCELLED. This asks the server not to transfer additional data and
 indicates that it will be discarded upon receipt.
 
+Pushed responses that are cacheable (see Section 3 of {{!RFC7234}}) can be

This is okay for now, but it should be improved eventually to talk about browser state separately from the cache. IOW, define push as part of the browser history (prehistory) because this is entirely separate from a cache (even if they use the same storage handles).

-- 
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/3407#pullrequestreview-353785369

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 05 Feb 2020 07:06:06 -0800

-A CONNECT request in HTTP/3 functions in the same manner as in HTTP/2. The
-request MUST be formatted as described in Section 8.3 of {{!HTTP2}}. A CONNECT
-request that does not conform to these restrictions is malformed (see
-{{malformed}}). The request stream MUST NOT be closed at the end of the request.
+A CONNECT request in HTTP/3 functions in the same manner as in HTTP/2.
+The request MUST be constructed as follows:
+
+- The ":method" pseudo-header field is set to "CONNECT"
+- The ":scheme" and ":path" pseudo-header fields are omitted
+- The ":authority" pseudo-header field contains the host and port to connect to
+  (equivalent to the authority-form of the request-target of CONNECT requests
+  (see Section 5.3 of [RFC7230]))
+- The request stream is not closed at the end of the request

IIUC this PR has a change in normative text from "MUST NOT be closed" to "is not closed". The issue that this PR addresses  is marked editorial.

-- 
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/3407#pullrequestreview-353788047

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 05 Feb 2020 07:08:38 -0800

Perhaps the "MUST be constructed" is intended to maintain the intent of the previous text. I don't think it achieves that because the stream lifetime is independent from the message.

-- 
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/3407#discussion_r375312125

---

From: Mike Bishop <[email-masked]>
Date: Tue, 11 Feb 2020 15:05:52 -0800

MikeBishop commented on this pull request.

Possibly, but not a hard one.  GOAWAY permits the endpoints to agree on state, so I'm content not to order them.

-- 
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/3407#discussion_r377953019

---

From: Mike Bishop <[email-masked]>
Date: Tue, 11 Feb 2020 15:07:09 -0800

Push isn't part of the cache, but it does use the definition of "cacheable" -- do you think it should be pointing elsewhere?

-- 
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/3407#discussion_r377953464

---

From: Mike Bishop <[email-masked]>
Date: Tue, 11 Feb 2020 15:16:50 -0800

@MikeBishop pushed 2 commits.

0e97c8e64baf14d5bd496ae1bb39ef22cd5317b8  Import most H2 references
c1a16dd55b9853d2cd8af3d02375eb672296d6ae  Review feedback

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3407/files/494eca8b19db3966ae044fc1453efb596cfc5ded..c1a16dd55b9853d2cd8af3d02375eb672296d6ae

---

From: Martin Thomson <[email-masked]>
Date: Tue, 11 Feb 2020 16:50:59 -0800

martinthomson commented on this pull request.

Generally good.  A few corner cases seem problematic though.

> -requests MUST conform to the requirements in Section 8.2 of {{!HTTP2}}.
+{{frame-push-promise}}) on the request stream which generated the push. This
+allows the server push to be associated with a client request.
+
+Not all requests can be pushed.  A server MAY push requests which have the
+following properties:
+
+- cacheable (see Section 4.2.3 of [RFC7231])
+- safe (see Section 4.2.1 of [RFC7231])
+- does not include a request body
+
+Clients SHOULD send a CANCEL_PUSH frame upon receipt of a PUSH_PROMISE frame
+carrying a request which is not cacheable, is not known to be safe, or that
+indicates the presence of a request body.  If the pushed response arrives on a
+push stream, this MAY be treated as a stream error of type
+H3_STREAM_CREATION_ERROR.

This is a bit weird in the sense that some of this is just an error.  If I get a PUSH_PROMISE with `Content-Length > 0`, why would I cancel it rather than treat that as an error?  

Whether something is "cacheable" might be unknowable based on the request alone, but some errors are pretty sharp.  There are other cases which are less clear too, such as `Content-Type` maybe indicating the presence of a request body, so I get how this might be tricky to handle in the general case.

> -{{malformed}}). The request stream MUST NOT be closed at the end of the request.
+In HTTP/1.x, CONNECT is used to convert an entire HTTP connection into a tunnel
+to a remote host. In HTTP/2 and HTTP/3, the CONNECT method is used to establish
+a tunnel over a single stream.
+
+A CONNECT request MUST be constructed as follows:
+
+- The ":method" pseudo-header field is set to "CONNECT"
+- The ":scheme" and ":path" pseudo-header fields are omitted
+- The ":authority" pseudo-header field contains the host and port to connect to
+  (equivalent to the authority-form of the request-target of CONNECT requests
+  (see Section 5.3 of [RFC7230]))
+
+A CONNECT request that does not conform to these restrictions is malformed (see
+{{malformed}}).  The request stream MUST NOT be closed at the end of the
+request.

This last sentence can go.  It is entirely valid for the request stream to be closed without sending anything, though it is admittedly not always very useful.

-- 
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/3407#pullrequestreview-357122071

---

From: ianswett <[email-masked]>
Date: Sat, 15 Feb 2020 08:36:31 -0800

ianswett approved this pull request.

Thanks for writing this.

> @@ -331,6 +331,11 @@ respective HTTP control stream (see {{control-streams}}).
 
 ## Connection Reuse
 
+HTTP/3 connections are persistent.  For best performance, it is expected that

I think "persistent across multiple requests." or something similar would be clearer.

Would "HTTP/3 session," make more sense than QUIC connection, given we're talking about an HTTP/3 layer GOAWAY?

>  those listed here.
 
+TODO:  This is going to be a big import, probably worthy of its own PR.

Leftover?  If not, I'm not sure what this TODO is exactly indicating.

-- 
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/3407#pullrequestreview-355346651

---

From: Mike Bishop <[email-masked]>
Date: Wed, 19 Feb 2020 13:13:28 -0800

I think it's useful as an exception to the more general requirement that the stream get closed at the end of the request.  But yes, we can reword it to something like "MAY not be closed."  (I would say "need not be closed," except that an exception to a MUST elsewhere feels like it needs its own normative language.)

-- 
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/3407#discussion_r381547589

---

From: Mike Bishop <[email-masked]>
Date: Wed, 19 Feb 2020 13:14:32 -0800

"worthy of its own PR" => #3407 addresses all imports *except* Security Considerations.

-- 
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/3407#discussion_r381548109

---

From: Mike Bishop <[email-masked]>
Date: Tue, 25 Feb 2020 12:15:57 -0800

Requests can be cacheable, but have answers which turn out not to be cacheable.  The distinction we settled on for H2 was that you can only promise cacheable requests, but the response need not be cacheable.

Yes, all of this is an error.  The question is whether:
- it needs to be a stream error on the response that contains the push
- it can be detected at the right layer for that to happen

My reasoning is primarily that, if you need to decompress and examine the headers to determine whether something is in error, an immediate stream error is not the right response to mandate.  Instead, you mark the push as invalid -- cancel it, and reject the push stream if it purports to arrive.

Really, this is a case of the push being malformed, and the idea is to define a response to malformed pushes that's commensurate with malformed responses -- don't use it.

-- 
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/3407#discussion_r384102031

---

From: Mike Bishop <[email-masked]>
Date: Tue, 25 Feb 2020 12:16:37 -0800

@MikeBishop pushed 1 commit.

f2307d3906da97ab981d58e960707b7a40620b95  Ian's feedback

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3407/files/c1a16dd55b9853d2cd8af3d02375eb672296d6ae..f2307d3906da97ab981d58e960707b7a40620b95

---

From: Mike Bishop <[email-masked]>
Date: Wed, 26 Feb 2020 11:41:17 -0800

d5749e411d341f33d3162005990fe0674053fc44  Request staying open isn't normative

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3407/files/f2307d3906da97ab981d58e960707b7a40620b95..d5749e411d341f33d3162005990fe0674053fc44

---

From: Mike Bishop <[email-masked]>
Date: Wed, 26 Feb 2020 11:42:16 -0800

5983e50d44154438c4b4bce559d707b0db9ee501  Request staying open isn't normative

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3407/files/d5749e411d341f33d3162005990fe0674053fc44..5983e50d44154438c4b4bce559d707b0db9ee501