- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Mon, 10 Oct 2016 10:17:08 +1100
- 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