I think that this would be good as long as we treat it with hint level language. On Thu, Jun 4, 2015 at 12:02 AM, Erik Nygren <erik@nygren.org> wrote: > I agree that this would be quite helpful, especially for the use-case for > splitting off traffic that supports SNI to a separate alt-svc. Other > corner cases with TLS-terminating middleboxes, I can't see why those > alt-svc assignments couldn't persist past network changes. > > On Wed, Jun 3, 2015 at 8:09 PM, Ryan Hamilton <rch@google.com> wrote: > >> I'd love to see an extension like this! >> >> On Tue, Jun 2, 2015 at 12:01 AM, Mark Nottingham <mnot@mnot.net> wrote: >> >>> >>> > On 2 Jun 2015, at 2:13 am, Martin Thomson <martin.thomson@gmail.com> >>> wrote: >>> > >>> > On 31 May 2015 at 18:06, Mark Nottingham <mnot@mnot.net> wrote: >>> >> This is an interesting discussion to have in concert with #69 >>> regarding extensibility; if we make services containing unrecognised >>> extensions must-ignore, it would make this sort of thing much chattier; the >>> above as an after-the-fact extension would need to be this on the wire: >>> >> >>> >> Alt-Svc: h2=":443"; ma=3600, h2=":443"; ma=3600; persist >>> > >>> > Yep, but if we add it now, that concern is less of a problem because >>> > servers can send it will a reasonable expectation of it being >>> > understood. >>> >>> Absolutely. But, there's always the next extension… >>> >>> >>> -- >>> Mark Nottingham https://www.mnot.net/ >>> >>> >>> >> >
Received on Thursday, 4 June 2015 11:46:21 UTC