- From: Kari hurtta <hurtta-ietf@elmme-mailer.org>
- Date: Thu, 29 Sep 2016 07:49:04 +0300 (EEST)
- To: Mark Nottingham <mnot@mnot.net>
- CC: HTTP working group mailing list <ietf-http-wg@w3.org>, Patrick McManus <pmcmanus@mozilla.com>, Kari hurtta <hurtta-ietf@elmme-mailer.org>
> Early cut here, feedback welcome: > http://httpwg.org/http-extensions/opsec.html ( very quick read ) http://httpwg.org/http-extensions/opsec.html#rfc.section.2.1 | However, it is possible that the server might become confused about whether requests’ URLs have | a HTTP or HTTPS scheme, for various reasons; see Section 5.4. To assure that the alternative | service has opted into serving HTTP URLs over TLS, clients MUST check the “http-opportunistic” | well-known URI defined in Section 3 before directing HTTP requests to it. and then 5.4 Confusion Regarding Request Scheme http://httpwg.org/http-extensions/opsec.html#confuse and 3. The “http-opportunistic” well-known URI http://httpwg.org/http-extensions/opsec.html#well-known and either 2.2 Interaction with “https” URIs http://httpwg.org/http-extensions/opsec.html#rfc.section.2.2 | Because of the risk of server confusion about individual requests’ schemes (see Section 5.4), | clients MUST NOT mix “https” and “http” requests on the same connection unless the | http-opportunistic response’s origin object Section 3 has a “mixed-scheme” member whose value | is “true”. does not make clear that this “mixed-scheme” check must be done for http-opportunistic resource returned by chosen alternative service. After all it is chosen alternative service which can be confused about scheme. 2.1 Alternative Server Opt-In http://httpwg.org/http-extensions/opsec.html#rfc.section.2.1 there is | The chosen alternative service returns the same representation as the origin did for the | http-opportunistic resource. but that only apply when determining “reasonable assurances”. Or have I missed something? / Kari Hurtta
Received on Thursday, 29 September 2016 04:49:36 UTC