W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2016

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

From: Martin Thomson <martin.thomson@gmail.com>
Date: Mon, 10 Oct 2016 10:17:08 +1100
Message-ID: <CABkgnnVecDi-w3yxqRBaGqvrz7zGUoYd1z7QyaZVv2zzuySgmg@mail.gmail.com>
To: Kari hurtta <hurtta-ietf@elmme-mailer.org>
Cc: Mike Bishop <Michael.Bishop@microsoft.com>, HTTP working group mailing list <ietf-http-wg@w3.org>, Patrick McManus <mcmanus@ducksong.com>
On 9 October 2016 at 18:34, Kari hurtta <hurtta-ietf@elmme-mailer.org> wrote:
> I'm not sure about
>         421 Misdirected Request

421 is actually the right response code when the server is sure that
it is not authoritative for an origin.  However, this is case where
the server probably IS authoritative, we just want the resource to not
exist. (If you accept the premise, I don't think that it's a necessary
change, see Patrick's email about who is being protected).

> 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.
Received on Sunday, 9 October 2016 23:17:45 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 9 October 2016 23:17:50 UTC