Re: Sec-Scheme request header?

[Mark Nottingham <[e-mail]>]

On 13 Apr 2016, at 11:53 PM, Martin Thomson <[e-mail]> wrote:
> 
> On 13 April 2016 at 10:41, Patrick McManus <[e-mail]> wrote:
>> I think we were discussing the general milieu of request routing complexity
>> (421, coalescing, alt-svc, etc..).. and how the scheme was the one part of
>> the origin that isn't always available to the final consumer of the request
>> whether that is because it is h1 and not in the request at all, or whether
>> it is because in h2 it is carried in a transport level colon header..
> 
> 
> Mark suggested that all existing places that carry a scheme might end
> up being eroded, by virtue of them being known to intermediaries and
> stacks and the like.  For example, most server software gently
> converts absolute URIs into a bare path (sometimes ignoring the
> authority part, IIRC).
> 
> The Sec-Scheme idea was a way of getting an unequivocal signal from
> the client to the code serving a resource without all that mess
> getting in the way.
> 
> Why this wouldn't also be eroded in the same way is down to freshness.
> Next time, we'll try Sec-NoIMeanIt-Scheme. </snark>

Nope.

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. 

Cheers,


--
Mark Nottingham   https://www.mnot.net/