- 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