- From: Kari hurtta <hurtta-ietf@elmme-mailer.org>
- Date: Sun, 9 Oct 2016 10:34:16 +0300 (EEST)
- To: Mike Bishop <Michael.Bishop@microsoft.com>, HTTP working group mailing list <ietf-http-wg@w3.org>
- CC: Martin Thomson <martin.thomson@gmail.com>, Kari Hurtta <hurtta-ietf@elmme-mailer.org>, Patrick McManus <mcmanus@ducksong.com>, HTTP working group mailing list <ietf-http-wg@w3.org>
> What if http://.../.w-k/h-o MUST exist (200) and https:// .../.w-k/h-o MUST NOT exist (404)? If a client checks both of those things, it has actually proven scheme handling rather than just asked the server to promise. ( status 200 with empty /.well-known/http-opportunistic or html /.well-known/http-opportunistic does not really tell that http: -scheme is handled. It MUST also return application/json Content-Type and at least json SHOULD be parsed and verified) So GET http://www.example.com/.well-known/http-opportunistic HTTP/1.1 from origin and alternative service can be done same time. These two MUST be same. GET https://www.example.com/.well-known/http-opportunistic HTTP/1.1 must either use new connection or if same connection is used first need wait that http-opportunistic is parsed and there is "mixed-scheme" member with value "true" for the origin "http://www.example.com/". I think that following should be allowed for not exist: 404 Not Found TBD1 Scheme Not Allowed (this RFC) 501 Not Implemented I'm not sure about 421 Misdirected Request 2.2. Interaction with "https" URIs https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-07#section-2.3 | Because of the risk of server confusion about individual requests' | schemes (see Section 4.4), clients MUST NOT send "http" requests on a | connection that has previously been used for "https" requests, unless | the http-opportunistic origin object Section 2.3 fetched over that | connection has a "mixed-scheme" member whose value is "true". I think that RFC can also require opposite. Add: And clients MUST NOT send "https" requests on a connection that has previously been used for "http" requests, unless the http-opportunistic origin object has a "mixed-scheme" member whose value is "true" That https: not exist -check perhaps can be on that section also. Client MUST check that "http-opportunistic" well-known URI is not retriable with using "https" scheme for an alternative service before using for "http" origin. Note: If the http-opportunistic origin object has no "mixed-scheme" member with value "true", then check need to be done with different connection than what was used for getting http-opportunistic response for "http" scheme. Client SHOULD NOT use selected alternative service for "http" origin unless "http-opportunistic" well-known URI via "https" scheme returned HTTP status code ∘ 404 (Not Found), or ∘ TBD1 (Scheme Not Allowed), or ∘ 501 (Not Implemented). ( SHOULD NOT so that there is some leeway for what HTTP status codes are considered to be not existing resource. ) The TBD1 (Scheme Not Allowed) status code indicates that used scheme is not allowed for the request. 3. IANA Considerations https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-07#section-3 add: This specification registers a (HTTP) Status Codes: [TO BE REMOVED: Hypertext Transfer Protocol (HTTP) Status Code Registry http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml ] +-------+-------------------------------+-------------+ | Value | Description | Reference | +-------+-------------------------------+-------------+ | TBD1 | Scheme Not Allowed | Section 2.2 | | TBD2 | Scheme Required | Section 2.1 | +-------+-------------------------------+-------------+ [TO BE REMOVED: TBD1 and TBD2 are from 4xx range. ] I wrote at https://lists.w3.org/Archives/Public/ietf-http-wg/2016OctDec/0097.html | When client send "http" requests over a TLS connection request | request MUST include scheme. This means that when used with | protocol identifier "http/1.1" (TTP/1.1 over TLS), request uses | absoluteURI -form. for "2.1. Alternative Server Opt-In" ( Better title: 2.1. Using "http" scheme over TLS connection) This chapter can include: Server MAY return http status code TBD2 (Scheme Required) if request does not include scheme. The TBD2 (Scheme Required) status code indicates that scheme is required for request. This means that server requires absoluteURI -form to be used for HTTP/1.1 -request. / Kari Hurtta
Received on Sunday, 9 October 2016 07:34:48 UTC