Subject: Re: [httpwg/http-extensions] rough in ORIGIN_SUPPORT (#406)

From: HTTP issue updates <[email-masked]>
Date: Tue, 26 Sep 2017 19:07:15 -0700

@enygren @MikeBishop please review.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/406#issuecomment-332387709

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 27 Sep 2017 03:19:13 +0000 (UTC)

martinthomson commented on this pull request.

It's getting there, but I think that a few more tweaks are needed.

> @@ -72,6 +72,18 @@ as described in BCP 14 {{!RFC2119}} {{!RFC8174}} when, and only when, they appea
 capitals, as shown here.

+# The ORIGIN_SUPPORT HTTP/2 Setting {#setting}
+
+The ORIGIN_SUPPORT HTTP/2 setting {{!RFC7540}}, Section 6.5) indicate that a server
+desires the connection to be considered "opted in" to the behaviour described in this specification.
+
+The value of the ORIGIN_SUPPORT setting does not have any meaning. Note that support for this
+specification cannot be disabled once it is sent.

We've used default = 0 and supported = 1 in the past.  I think that I'd prefer that.

-The origin frame MUST be sent on stream 0; an ORIGIN frame on any other stream is invalid and MUST
-be ignored.
+The ORIGIN frame MUST be sent on stream 0; an ORIGIN frame on any other stream is invalid and MUST
+be ignored. The ORIGIN frame MUST be ignored if the ORIGIN_SUPPORT setting ({{setting}} has not be

s/}}/}})/
s/not be/not been/

> @@ -72,6 +72,18 @@ as described in BCP 14 {{!RFC2119}} {{!RFC8174}} when, and only when, they appea
 capitals, as shown here.

+# The ORIGIN_SUPPORT HTTP/2 Setting {#setting}
+
+The ORIGIN_SUPPORT HTTP/2 setting {{!RFC7540}}, Section 6.5) indicate that a server
+desires the connection to be considered "opted in" to the behaviour described in this specification.
+
+The value of the ORIGIN_SUPPORT setting does not have any meaning. Note that support for this
+specification cannot be disabled once it is sent.
+
+ORIGIN_SUPPORT has no effect on servers, and MUST be ignored by them. Likewise, it MUST be ignored
+by clients who have configured a proxy.
+

Please describe what semantics you want to associate with the *client* sending the setting.

> @@ -147,16 +159,16 @@ See {{algo}} for an illustrative algorithm for processing ORIGIN frames.
 The set of origins (as per {{!RFC6454}}) that a given connection might be used for is known in this
 specification as the Origin Set.
 
-By default, the Origin Set for a connection is uninitialised. When an ORIGIN frame is first received
-and successfully processed by a client, the connection's Origin Set is defined to contain an initial
-origin.  The initial origin is composed from:
+By default, the Origin Set for a connection is uninitialised. When the ORIGIN setting ({{setting}})

I think that you want to change the "By default" here too.  Perhaps:

"On a connection where the server has not sent an ORIGIN_SUPPORT setting, the rules for authority in Section 9.1.2 of {{!RFC7540}} apply and the Origin Set is not used."  ... or something.

s/ORIGIN/ORIGIN_SUPPORT/

> @@ -165,19 +177,19 @@ Section 6.2) and remove it from the connection's Origin Set, if present.
 
 Note:
 
-: When sending an ORIGIN frame to a connection that is initialised as an Alternative Service
+: When sending an ORIGIN setting on a connection that is initialised as an Alternative Service

ORIGIN_SUPPORT again

>    {{?RFC7838}}, the initial origin set ({{set}}) will contain an origin with the appropriate
   scheme and hostname (since Alternative Services specifies that the origin's hostname be sent
   in SNI). However, it is possible that the port will be different than that of the intended
   origin, since the initial origin set is calculated using the actual port in use, which can be
   different for the alternative service. In this case, the intended origin needs to be sent in
-  the ORIGIN frame explicitly.
+  a subsequent ORIGIN frame explicitly.
 
 : For example, a client making requests for "https://example.com" is directed to an alternative
   service at ("h2", "x.example.net", "8443").  If this alternative service sends an ORIGIN

ORIGIN_SETTING

> @@ -192,11 +204,11 @@ authoritative, both in HEADERS and PUSH_PROMISE frames from the server ({{!RFC75
 generally only send requests on connections that they believe to be authoritative for the origin in
 question.
 
-Once an Origin Set has been initialised for a connection, clients that implement this specification
-use it to help determine what the connection is authoritative for. Specifically, such clients MUST
-NOT consider a connection to be authoritative for an origin not present in the Origin Set, and
-SHOULD use the connection for all requests to origins in the Origin Set for which the connection is
-authoritative, unless there are operational reasons for opening a new connection.
+Once ORIGIN_SUPPORT has been received on a connection, clients that implement this specification

"Once the ORIGIN_SUPPORT setting has been received"

 The following algorithm illustrates how a client could handle received ORIGIN frames:
 
-1. If the client is configured to use a proxy for the connection, ignore the frame and stop processing.
-2. If the connection is not identified with the "h2" protocol identifier or another protocol that has explicitly opted into this specification, ignore the frame and stop processing.
-3. If the frame occurs upon any stream except stream 0, ignore the frame and stop processing.
-4. If any of the flags 0x1, 0x2, 0x4 or 0x8 are set, ignore the frame and stop processing.
-5. If no previous ORIGIN frame on the connection has reached this step, initialise the Origin Set as per {{set}}.
+1. If the client has not received an ORIGIN_SUPPORT setting on the connection, ignore the frame and stop processing.
+2. If the client is configured to use a proxy for the connection, ignore the frame and stop processing.
+3. If the connection is not identified with the "h2" protocol identifier or another protocol that has explicitly opted into this specification, ignore the frame and stop processing.
+4. If the frame occurs upon any stream except stream 0, ignore the frame and stop processing.

Should we have it generate an error?  Also, that suggests moving this step to the first step so that we can catch more errors.

 Generally, this information is most useful to send before sending any part of a response that might
 initiate a new connection; for example, `Link` headers {{?RFC5988}} in a response HEADERS, or links
 in the response body.
 
-Therefore, the ORIGIN frame ought be sent as soon as possible on a connection, ideally before any
-HEADERS or PUSH_PROMISE frames.
+Therefore, the ORIGIN_SUPPORT setting and any ORIGIN frames ought be sent as soon as possible on a
+connection, ideally before any HEADERS or PUSH_PROMISE frames.

I think that you want to point out that the ORIGIN_SUPPORT setting should be sent in the connection preface, and separately that ORIGIN frames need to be sent as early as possible.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/406#pullrequestreview-65417475

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 26 Sep 2017 20:21:53 -0700

mnot commented on this pull request.

 capitals, as shown here.

That will cause people to assume they can turn it off; is it worth the added complexity / misunderstanding?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/406#discussion_r141236563

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 27 Sep 2017 03:21:56 +0000 (UTC)

capitals, as shown here.

It has none, as above.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/406#discussion_r141236565

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 26 Sep 2017 20:23:01 -0700

Hmm. Possibly. Which step is 'this'?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/406#discussion_r141236662

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 27 Sep 2017 03:23:20 +0000 (UTC)

yup.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/406#discussion_r141236696

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 26 Sep 2017 20:27:46 -0700

capitals, as shown here.

Hmm, that's nasty.  I don't know.  Consistency is valuable though.

How about you mandate a value of 1.  Anything else is an error.

 capitals, as shown here.

Ahh, ignored by servers.  Yuck.  Can we just make the server generate an error instead?

Step 4 (frame on streams other than 0)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/406#discussion_r141236970

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 27 Sep 2017 16:40:03 +0000 (UTC)

MikeBishop requested changes on this pull request.

Mostly minor nits.  The Alt-Svc feedback is separate from this PR, so feel free to merge without addressing that.

 capitals, as shown here.

In HTTP/QUIC, it can be a Boolean (sent = true), but HTTP/2 has to have a value.  I'm on the mandate-value-of-1 wagon.

I'll second that.  If the server doesn't declare support, return to the RFC the server knows it's implementing.

-By default, the Origin Set for a connection is uninitialised. When an ORIGIN frame is first received
-and successfully processed by a client, the connection's Origin Set is defined to contain an initial
-origin.  The initial origin is composed from:
+By default, the Origin Set for a connection is uninitialised. When the ORIGIN setting ({{setting}})
+is received by a client, the connection's Origin Set is defined to contain an initial origin. The
+initial origin is composed from:
 
   - Scheme: "https"
   - Host: the value sent in Server Name Indication (SNI, {{!RFC6066}}, Section 3), converted to lower case
   - Port: the remote port of the connection (i.e., the server's port)

I continue to be a little sad about the port's interaction with Alt-Svc.  At this point, we're saying that the client opened the connection to speak to a particular origin (example.com:443) via an Alternative at a different port (alt.example.com:8443).  So upon receipt of the server's settings, the connection will be valid for requests bound to https://example.com:8443, which is no outstanding request on the client, and the client can't legitimately make requests until it receives the ORIGIN frame.

If https://example.com:443 and https://example.com:8443 Alt-Svc to alt.example.com:8443, then the server can't know which origin the client thinks it's talking to except by the requests it makes.  I still think I'd initialize this to the origin (including port) which prompted opening the connection, rather than the actual server port.  The server doesn't necessarily need to know this value before the client makes a request.

ORIGIN_SUPPORT

> @@ -224,6 +236,13 @@ This specification adds an entry to the "HTTP/2 Frame Type" registry.
 * Code: 0xc
 * Specification: [this document]
 
+This specification adds an entry to the "HTTP/2 Settings" registry.
+
+* Name: ORIGIN_SUPPORT
+* Code: assign_me
+* Initial Value: (any value)

Let's follow convention and make the initial value 0.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/406#pullrequestreview-65604701

---

From: HTTP issue updates <[email-masked]>
Date: Thu, 28 Sep 2017 11:17:13 +0000 (UTC)

Lekensteyn commented on this pull request.

Can the behavior of late ORIGIN frames be defined? As I currently read the spec, the Origin set can be modified in the full stream lifetime, so even after HEADERS or PUSH_PROMISE frames.

When the server was unable to prepare the Origin frame (e.g. due to validation delays), can it send it anyway as hint for future requests?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/406#discussion_r141590318