- From: Mark Nottingham <mnot@mnot.net>
- Date: Mon, 8 Jun 2015 11:35:10 +1000
- To: Patrick McManus <mcmanus@ducksong.com>
- Cc: Erik Nygren <erik@nygren.org>, Ryan Hamilton <rch@google.com>, Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Proposal here: https://github.com/httpwg/http-extensions/commit/c592c6424f4b0cc1250cb417ceb2a7444fc23e1b > On 4 Jun 2015, at 9:45 pm, Patrick McManus <mcmanus@ducksong.com> wrote: > > 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/ > > > > > -- Mark Nottingham https://www.mnot.net/
Received on Monday, 8 June 2015 01:35:41 UTC