W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2016

2.2. Interaction with "https" URIs | Re: SETTINGS_MIXED_SCHEME_PERMITTED | Re: I-D Action: draft-ietf-httpbis-http2-encryption-07.txt

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>
Message-Id: <20161009073417.6A669113F0@welho-filter1.welho.com>
> 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)

  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

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


   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


  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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:56 UTC