I think I agree with Kari - this is per origin and not per connection.. having implemented the .wk thing I found it pretty workable and the server side folks liked that this could be done with simply configuration to reflect origin policy via headers and .wk rather than a protocol extension. On Wed, Oct 5, 2016 at 6:51 AM, Kari Hurtta <hurtta-ietf@elmme-mailer.org> wrote: > Mike Bishop <Michael.Bishop@microsoft.com>: (Tue Oct 4 20:38:45 2016) > > > Taking a step back, what is the list of ports actually buying us now? > The port can be obtained by the client from the Alt-Svc header. The fact > that the port is legitimate and not hijacked is verified by finding that it > has a certificate. What we're actually confirming is that the origin > supports mixed schemes. The lifetime is already present in the Alt-Svc > advertisement, and I haven't heard a compelling reason to have a separate > lifetime. Should we just define SETTINGS_MIXED_SCHEME_PERMITTED and call > it a day? > > Hmm. > > SETTINGS_MIXED_SCHEME_PERMITTED is per connection. I assume that HTTP/2 > server sends it on SETTINGS frame to HTTP/2 client (similar than what > I contemplated for SETTINGS_WEBSOCKET_CAPABLE at > https://lists.w3.org/Archives/Public/ietf-http-wg/2016OctDec/0033.html ) > > http-opportunistic response tells here that given port for that > origin handles http -scheme when sent via TLS. > > 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. > > "tls-ports" should perhaps now be "mixed-scheme-listeners" > giving [ "alternative-server:port" ]. > > / Kari Hurtta > > >
Received on Wednesday, 5 October 2016 08:54:05 UTC