2.2. Interaction with "https" URIs | Re: Op-sec simplification

[Kari Hurtta <[e-mail]>]

> | https://github.com/httpwg/http-extensions/pull/254
> | 
> | The main changes:
> | 
> |  - the .well-known resource is a flat list of origins
> 
> ( no comment about that yet. )
> 

On earlier version there was concern that if
same connection was used both on "http" 
and "https" scheme then these are
confused by server.

Therefore there was requirement that clients must 
not send "http" requests on a connection that would
ordinarily be used for "https" requests.

There was  "mixed-scheme" flag what disabled that
requirement.

Now there is no that requirement:

https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-08#section-2.2

| 2.2.  Interaction with "https" URIs
|
|   When using alternative services, requests for resources identified by
|   both "http" and "https" URIs might use the same connection, because
|   HTTP/2 permits requests for multiple origins on the same connection.
|   Because of the potential for server confusion about the scheme of
|   requests (see Section 4.4), clients MUST NOT send "http" requests on
|   a connection prior to successfully retrieving a valid http-
|   opportunistic resource that contains the origin (see Section 2.3).
|   The primary purpose of this check is to provide a client with some
|   assurance that a server understands this specification and has taken
|   steps to avoid being confused about request scheme.

What is wanted ?  Options

	• No concern; that check that http://{...}/.well-known/http-opportunistic
          succeed tells enough that there is no confusion

        • Forbid using same connection for "http" requests
	  which would ordinarily be used for "https" requests.

	• Forbid using same connection for "http" requests
          which would ordinarily be used for "https" requests
	  but allow it if there is "mixed-scheme" -member (or
	  some other flag).

        • Forbid using same connection for "http" requests
	  which would ordinarily be used for "https" requests
	  unless same connection which was tested
	  for http://{...}/.well-known/http-opportunistic
	  are also after that tested:

		∘ That https requests for /.well-known/http-opportunistic
		  on same host {...} does not return same object

		∘ Note that if that test fails, then that connection
		  is no longer be good for http requests either.
		
/ Kari Hurtta