W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: :scheme, was: consensus on :query ?

From: Zhong Yu <zhong.j.yu@gmail.com>
Date: Thu, 24 Jul 2014 00:19:50 -0500
Message-ID: <CACuKZqFMJ7zWZ-aGJ8HfbGQtL0NQfWyjzXn2MrckZddzf8f-sA@mail.gmail.com>
To: Greg Wilkins <gregw@intalio.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
If a request self-claims that it is HTTPS, I think the server should
just take its word for it. If a client lies about the scheme, the
client does it at its own peril, and it should have the freedom to do
so. If an intermediary (possibly a man-in-the-middle) lies about the
scheme, there's not much the server can do about it.

The problem in HTTP/1 is that the server has no reliable way to know
whether the request was originated as HTTPS at the client end,
(assuming client/intermediaries are all honest), because the request
could have gone through multiple intermediaries that alternate
TLS/PLAIN connections.

There is an unofficial header "X-Forwarded-Proto" to record the
upstream scheme, which the server should take into account when it's
present (e.g. for Request.isSecure() API). However it is very unclear,
from reading proxy/load-balancer documents, how would the header
record multiple entries, and how are these entries corresponding to
entries in the "X-Forwarded-For" header.

Zhong Yu
bayou.io

On Wed, Jul 23, 2014 at 11:35 PM, Greg Wilkins <gregw@intalio.com> wrote:
>
> While we are talking about decomposing the uri into it's component
> parts.....
>
> why are we sending :scheme?
>
> It's not something that I would trust from a client anyway.
>
> If the connection is not TLS and the request says https, then I'm not going
> to believe it.  The only way I'll upgrade a request to https is with some
> secret handshake with my SSL offloader via a special privileged port that
> will probably nail all requests to https regardless of what the header says.
>
> If the connection is TLS and the scheme says http, then I guess that tells
> me something... that it is not TLS end to end, but then I don't know if I'm
> meant to be trusting the hop or the end to end.    It's landing on my server
> as https... so I guess it is.
>
> Or is scheme meant to be optional, as in h1 allowing an absolute URL to be
> sent in the request line?
>
> --
> Greg Wilkins <gregw@intalio.com>
> http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
> http://www.webtide.com  advice and support for jetty and cometd.
Received on Thursday, 24 July 2014 05:20:17 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:09 UTC