- From: Ilari Liusvaara <ilariliusvaara@welho.com>
- Date: Wed, 5 Oct 2016 23:31:06 +0300
- To: Mike Bishop <Michael.Bishop@microsoft.com>
- Cc: Kari Hurtta <hurtta-ietf@elmme-mailer.org>, HTTP working group mailing list <ietf-http-wg@w3.org>
On Wed, Oct 05, 2016 at 05:28:20PM +0000, Mike Bishop wrote:
>
> As for moving forward with this, I think it depends on just what we're trying to validate. Let's agree on the question before we argue about the answer. Is it:
>
> - This host is authorized to serve the content for http://example.com? That's RFC 7838 -- we're done.
> - This host can serve the content for http://example.com and is smart enough not to get confused when scheme and port don't match? Again, that's RFC 7838 ("mitigate ... by refraining from advertising alternative services for insecure schemes."). But if you want to enable clients to double-check the origin administrators, let the alternative declare that it's scheme-aware, whether by existence of a .w-k resource or a connection setting.
> - This host can serve content for both http://example.com *and* https://example.com *and* http://other.example.com on the same connection without confusing them all? That seems to be implied by the previous one.
> - This host *consents* to serve http://example.com? Seems implicit in responding to requests. What does anyone gain by checking before sending requests versus trying the requests and maybe getting 421s?
Then there is the problem what to do if client sends a :scheme value
the server/rproxy does not know anything about, not even how to properly
reject it.
In the original proposal, I proposed adding a new stream error type for
rejecting such streams.
-Ilari
Received on Wednesday, 5 October 2016 20:31:46 UTC