Re: SETTINGS_MIXED_SCHEME_PERMITTED | Re: I-D Action: draft-ietf-httpbis-http2-encryption-07.txt

Mike Bishop <Michael.Bishop@microsoft.com>: (Wed Oct  5 20:28:20 2016)
> I'm having trouble envisioning the scenario where you need to split this by origin, though.  Our concerns here are about server implementations that ignore the scheme component and simply rely on the incoming port to provide that information, right?.  That means you need to get that information on a port-by-port (i.e. server/connection) basis.  Is there a scenario where alternate.example.com:443 is capable of parsing mixed-scheme requests for one origin, but blind to it for another?  Here are the cases I can think of:
> 
>   - Actual server with multiple origins:  It may or may not be configured to *serve* http:// scheme for all origins from that port, but that's indicated by the Alt-Svc headers pointing to it.  Mistaken requests would get a 421.
>   - TLS-terminating load balancer:  The connection inside TLS will still reach a single back-end server, so see previous item.
>   - HTTP reverse proxy:  The sites behind it may indeed have different capabilities, but that's strictly a function of how the reverse proxy obtains the resources, not something the client needs to validate.

This is seemingly about that part of my comment:

  >> connection apply probably for several origins. TLS connection
  >> may be terminated by reverse proxy. And different origins
  >> are served by different processes or servers behind of
  >> reverse proxy.
  >>
  >> I guess that SETTINGS_MIXED_SCHEME_PERMITTED is too wide.

Yes, that depends what you want validate.

I was envisioning that selection of back end server spool
on reverse proxy / load balancer is function of origin.

( Yes, this imply that TLS is terminated here )

Effectively you are saying that selection of back 
end server spool on reverse proxy / load balancer 
must be function of origin AND scheme. Or that
that reverse proxy / load balancer must check scheme.

Yes, it is possible to require that SETTINGS_MIXED_SCHEME_PERMITTED
is not sent if reverse proxy / load balancer does not
check itself scheme.

If reverse proxy / load balancer checks scheme and
found that http: is used, it need get SETTINGS_MIXED_SCHEME_PERMITTED
from backend server (if HTTP/2 is used) or use
white list for secure backend servers / pools
or refuse request.

White list tells that which backend servers / pools
check scheme, in that case http:  -request can be
sent ot here.

If selection of back end server / server pool is
function of origin AND scheme, then request
can be sent to that server / pool which is 
for http: -scheme.


> Again, that's RFC 7838 ("mitigate ... by refraining from advertising alternative services for insecure schemes.").

That is

|   refraining from advertising alternative services for insecure schemes
|   (for example, HTTP).


And whole draft is about advertising alternative services for
http -scheme.

I'm really confused.

> Can someone ELI5?

I do not found that from dictionary.

/ Kari Hurtta

Received on Wednesday, 5 October 2016 19:34:33 UTC