Re: Sec-Scheme request header?

On 14/04/2016 8:06 p.m., Mike West wrote:
> On Thu, Apr 14, 2016 at 10:00 AM, Mark Nottingham wrote:
> 
>> This is something that would be really useful for disambiguating things in
>> cases where the same server-side code is handling both HTTP and HTTPS URLs.
>>
> 
> I think I'd prefer to encourage folks to treat HTTP and HTTPS as "the same"
> with regard to the resource which is being universally {identified,
> located}. I freely admit, however, that I'm not at all familiar with what
> developers do with backend servers and proxies and CDNs, so I'm sure there
> are solid use cases I'm missing. Could you point me to some?
> 
> -mike
> 

Taking the abstract view we have several cases:

1) anything talking to legacy install 1.1 servers
 - nothing helps here. old software ignores new features.
 - when its upgraded the new software will become h2-enabled right?
which makes it move to another case.

2) h2 enabled server/gateway talking to legacy install 1.1 client
 - nothing helps here.
 - thats the clients fault, and when upgraded will become h2-enabled
which is a higher numbered case.

3) h2 client talking to h2 server.
 - just use :scheme. Wins all around.

4) h2 enabled client/server endpoints talking over 1.1 middleware
 - Scheme: might help.

BUT actually using absolute-URL for the request-target would help more.
Since it helps ensure the scheme + host are treated as a pair and not
getting separated or confused.

BUT, lets be honest explicit-proxy middleware is already using
absolute-URL so case #4 is only a problem when interception MITM are
present.


So the radical and politically incorrect proposal:
  begin a campaign to get clients to just use absolute-URL over 1.1
regardless of the connection type. Port 80, port 443, taking to an
explicit proxy - no more special casing just send absolute-URL.

In its favour this campaign can be done with just a consensus and small
amount of conspiracy to actually implement by us WG participants. It
does not require full h2 implementation to participate, and there is a
slight/rare chance it might actually do something useful for case #1.
And it simplifies and should speed up processing in both browsers and
the annoyingly slow MITM middleware.

On the downside we hit an (unkown?) amount of servers not complying with
the RFC requirement to accept absolute-URL. And other weirdness, like
ignoring it in favour of Host (which could be dropped BTW, more savings!).


Amos

Received on Thursday, 14 April 2016 10:25:49 UTC