- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Wed, 5 Oct 2016 23:43:13 +1100
- To: Patrick McManus <mcmanus@ducksong.com>
- Cc: Kari Hurtta <khurtta@welho.com>, Mike Bishop <Michael.Bishop@microsoft.com>, Kari hurtta <hurtta-ietf@elmme-mailer.org>, HTTP working group mailing list <ietf-http-wg@w3.org>
And now that I read this thread, I find that the point about origins over connections is pretty convincing. I should read all before committing to mistakes :) However, perhaps there is some simplification to be salvaged. I think that Mike's observation suggests that we can remove "tls-ports". Once the TLS-enabled port acknowledges that it understand that it can receive requests for http://<foo> then maybe that's enough (in addition to it having a valid certificate, that is). And, while I'm on the topic, "lifetime" is a bit jarring now that we don't have a commitment. To that end, a simpler formulation suggests itself: [ "http://example.com", "http://example.com:5602" ] That should make Mark happy about not having to reconcile "lifetime" with the cache freshness lifetime. On 5 October 2016 at 19:53, Patrick McManus <mcmanus@ducksong.com> wrote: > 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 12:43:42 UTC