Subject: Re: Alt-Svc #71: Hints for Flushing

From: Martin Thomson <[email-masked]>
Date: Mon, 1 Jun 2015 09:13:59 -0700

On 31 May 2015 at 18:06, Mark Nottingham <[email-masked]> 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.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 2 Jun 2015 17:01:52 +1000

> On 2 Jun 2015, at 2:13 am, Martin Thomson <[email-masked]> wrote:
> 

Absolutely. But, there's always the next extension…

--
Mark Nottingham   https://www.mnot.net/

---

From: Ryan Hamilton <[email-masked]>
Date: Wed, 3 Jun 2015 17:09:19 -0700

I'd love to see an extension like this!

On Tue, Jun 2, 2015 at 12:01 AM, Mark Nottingham <[email-masked]> 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:
> >>

---

From: Erik Nygren <[email-masked]>
Date: Thu, 4 Jun 2015 00:02:33 -0400

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 <[email-masked]> 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:
>> >>

---

From: Patrick McManus <[email-masked]>
Date: Thu, 4 Jun 2015 07:45:57 -0400

I think that this would be good as long as we treat it with hint level
language.

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 8 Jun 2015 11:35:10 +1000

Proposal here:
  https://github.com/httpwg/http-extensions/commit/c592c6424f4b0cc1250cb417ceb2a7444fc23e1b

> On 4 Jun 2015, at 9:45 pm, Patrick McManus <[email-masked]> wrote:
> 
> I think that this would be good as long as we treat it with hint level language.
> 
> 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.
>

---

From: Erik Nygren <[email-masked]>
Date: Mon, 8 Jun 2015 17:49:46 -0400

Perhaps we should define a extension value now ("comprehensive"?) that
requires the client to know ignore that entry if all extension fields
aren't understood but switch the default to "ignore extension fields you
don't understand"?  So far the extension fields that have been proposed (a
"q=" value for weighting/experiments as well as "persist") both seem to be
better off as hints to just be ignored if not understood.

       Erik

---

From: Martin Thomson <[email-masked]>
Date: Mon, 8 Jun 2015 14:52:07 -0700

On 8 June 2015 at 14:49, Erik Nygren <[email-masked]> wrote:
> requires the client to know ignore that entry if all extension fields aren't
> understood but switch the default to "ignore extension fields you don't
> understand"?  So far the extension fields that have been proposed (a "q="
> value for weighting/experiments as well as "persist") both seem to be better
> off as hints to just be ignored if not understood.

An alternative method is to include a parameter that lists
mandatory-to-understand parameters.