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 07:55:17 2016)
> On 10 October 2016 at 15:45, Kari Hurtta <[e-mail]> wrote:
> > After one "https" reguest that apply:
> >
> > |                            clients MUST NOT send "http" requests on a
> > |    connection that has previously been used for "https" requests,
> 
> The point of this is to cover off any problems that might arise from
> connection reuse.  It's clumsy.  I think that it should be reworded:
> clients MUST NOT send "http" requests on a connection that would
> ordinarily be used for "https" requests unless the http-opportunistic
> origin object [...]

That looks good.
 
> If scheme is determined on the first request and that causes this
> check to pass, then we're going to get false positives.  Remember:
> we're incapable of detecting all cases where the server decides to do
> crazy things - I'm sure that I can devise a server architecture that
> will fail for any solution we devise - we have to instead take steps
> that we think are reasonable.

I can image real word situation where scheme is checked only
on the first request. Namely load balancer which do routing
decision on first request and then same back end connection
is used for all requests. 

Yes, I can not guess all cases where server does grazy things.

( That is:
    route port 80 to pool1
    route port 443, scheme "http" to pool1
    route port 443, scheme "https" to pool2
)

/ Kari Hurtta