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

[Kari Hurtta <[e-mail]>]

Martin Thomson <[e-mail]>: (Mon Oct 10 02:17:08 2016)
> > 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"
> 
> I disagree.  The point of all this mucking around is to make it clear
> that special behaviour is permitted, making https requests over an
> authenticated TLS connection is perfectly normal and expected.

After one "https" reguest that apply:

|                            clients MUST NOT send "http" requests on a
|    connection that has previously been used for "https" requests,

So it is unusable for "http".

And if "http" and "https" are send consecutive on "h2", which
one is executed first?  

What is reason that  "mixed-scheme" is "true" requirement?

Is reason that
	∘ confusion happens if "http" follows "https", or 
	∘ scheme is determined only on first request ?

If any "https" can cause confusion, then there is also
danger on sequence "http" and then "https" assuming that
first is not completed before send is requested.

/ Kari Hurtta