- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Wed, 2 Nov 2016 11:52:35 +1100
- To: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
- Cc: HTTP working group mailing list <ietf-http-wg@w3.org>
On 2 November 2016 at 04:22, Kari Hurtta <hurtta-ietf@elmme-mailer.org> wrote:
> • No concern; that check that http://{...}/.well-known/http-opportunistic
> succeed tells enough that there is no confusion
I think that this is sufficient.
The reason that I think this is OK, and the reason for removing a
mixed-scheme flag was that the risk comes from confusion. That
confusion exists as soon as an http:// request is made over a TLS
connection.
It's not that much worse when things are mixed. The bad examples of
routing based on the first request are bad for many reasons. They are
simply cause to NOT provide the .well-known resource.
> • Forbid using same connection for "http" requests
> which would ordinarily be used for "https" requests.
We've already established that this is difficult to define properly.
And it's unnecessarily limiting.
> • 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).
As above.
> • 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.
As above, just more complicated :)
Received on Wednesday, 2 November 2016 00:53:09 UTC