Re: last call Feedback for Opportunistic Security for HTTP (Experimental)

> Early cut here, feedback welcome:

( very quick read )

| 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


3. The “http-opportunistic” well-known URI

and either

2.2 Interaction with “https” URIs

| 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

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