Re: Sec-Scheme request header?

On Thu, Apr 14, 2016 at 2:15 AM, Mark Nottingham <mnot@mnot.net> wrote:

> The motivation here is that there is no standard way to determine the
> client's idea of what the scheme is at the server in HTTP/1.x, and while we
> define :scheme in H2, we short-sightedly made it a pseudo-header, meaning
> that there's no standard way for it to be exposed to server-side code.
>
> This is especially evident in situations like those that Julian described,
> where a request might go through infrastructure like this:
>
> --> CDN --> Reverse Proxy --> Origin Server --> PHP runtime --> PHP
> framework --> Application code
>
> ... and :scheme information might be stripped at any of these stages.
>
> Right now, different servers, runtimes and frameworks have different ways
> of determining the context of the connection (using port numbers, static
> configuration, presence of TLS, etc.), leading to confusion and resulting
> potential for security problems.
>
> Having a clear signal about the scheme in use from the client that
> "punches through" all of this in a way that's easy for the frameworks and
> application code to access and reason about *seems* like it would be a
> useful thing for them.
>

What kind of reasoning do you expect this header to enable?

I'm a little worried about terminating TLS somewhere, but carrying a
"totally secure" indicator through various proxies and etc. until reaching
an origin server. Doesn't that seem more confusing and problematic than
status quo? "SSL added and removed here", and etc.

-mike