- From: Willy Tarreau <w@1wt.eu>
- Date: Thu, 24 Jul 2014 08:11:47 +0200
- To: Greg Wilkins <gregw@intalio.com>
- Cc: Matthew Kerwin <matthew@kerwin.net.au>, Adrien de Croy <adrien@qbik.com>, Zhong Yu <zhong.j.yu@gmail.com>, Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Thu, Jul 24, 2014 at 02:35:26PM +1000, Greg Wilkins 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?
In my opinion it's not used to know if the connection was secure or not, but :
1) for proxies, what scheme to use on the other side (remember the
discussions we had about secure proxies to which we could send
http:// requests over SSL)
2) for application servers, guess whether links in pages should be
built with http:// or https:// schemes so that the page displays
consistently in the browsers despite the presence of an SSL offloader
in front of the server. Currently this is handled using X-Forwarded-Proto
or X-SSL: True or whatever header field an offloader might add to inform
the server.
Thus I'd say that it only reflects the scheme the client desires to
use, nothing more.
Regards,
Willy
Received on Thursday, 24 July 2014 06:12:26 UTC