Re: How to reset ALTSVC

Some more discussion here is here:
https://github.com/httpwg/http-extensions/issues/16

The concern with empty string was summarized by Julian:

> I'm having second thoughts abound the "empty list" solution. In the past
> I've seen broken support for empty header field values (software components
> not being able to distinguish between "empty" and "not present").
>
and Patrick agreed with:

my instincts agree with Julian - empty headers with semantics are asking
> for trouble
>





On Wed, Aug 26, 2015 at 5:06 PM, Bence Béky <bnc@chromium.org> wrote:

> Hi,
>
> I noticed that the "clear" keyword was introduced
> <https://github.com/httpwg/http-extensions/commit/68970e3555ba77cd56418c036e601af520b17711>
> to clear alternative service entries for a given origin, but I don't seem
> to find any discussion about this on this mailing list.  Also, I was under
> the impression that when I brought it up at the last meeting, there was no
> objection to advertising an empty string for this purpose.  I'm just
> curious what happened.
>
> I personally find it still better than the "origin itself" or "bogus entry
> with ma=0" hacks, though not quite as clear and foolproof to implement as
> an empty string.  Alas, I would be interested to hear other people's
> opinions, in case anyone has experience implementing it since it was last
> discussed.
>
> Also, since "clear" clears entries including the ones in the same header,
> why could there be multiple alt-values?  Would instead of
>
> Alt-Svc       = 1#alt-value
> alt-value     = clear / ( alternative *( OWS ";" OWS parameter ) )
>
> the following:
>
> Alt-Svc       = clear / 1#alt-value
> alt-value     = alternative *( OWS ";" OWS parameter )
>
> not make more sense?
>
> Thanks,
>
> Bence
>
> On Wed, Apr 1, 2015 at 11:37 PM, Ryan Hamilton <rch@google.com> wrote:
>
>> On Wed, Apr 1, 2015 at 5:17 PM, Mark Nottingham <mnot@mnot.net> wrote:
>>
>>>
>>> > On 2 Apr 2015, at 10:02 am, Ryan Hamilton <rch@google.com> wrote:
>>> >
>>> > On Wed, Apr 1, 2015 at 9:24 AM, Martin Thomson <
>>> martin.thomson@gmail.com> wrote:
>>> > On 1 April 2015 at 05:11, Bence Béky <bnc@chromium.org> wrote:
>>> > > I think the simplest way to say "the alternative services for this
>>> > > origin is the following list: {empty list}" is to say "{empty list}"
>>> > > instead of "{one item identical to origin, which is understood to
>>> have
>>> > > the special meaning that it's an empty list}" or "{one item with
>>> valid
>>> > > but arbitrary port and a special, otherwise unused value for ma,
>>> which
>>> > > is understood to have the special meaning that it's an empty list}".
>>> >
>>> > That argument only makes sense if you don't consider the origin to be
>>> > a validate alternative.  That it's implicit and always present isn't
>>> > of much consequence.
>>> >
>>> > That's surprising to me. As I read the spec, Alt-Svc is all about
>>> specifying different ways to reach a server:
>>> >
>>> >    ...document specifies "alternative services" for HTTP, which allow
>>> >    an origin's resources to be authoritatively available at a separate
>>> >    network location
>>> >
>>> >
>>> > To me, that does not imply that the origin is present in the list of
>>> alternatives. If the origin is implicitly in that list, should Alt-Svc-Used
>>> be sent when using it? That doesn't seem reasonable to me, which makes me
>>> think that the origin really isn't implicitly part of the Alt-Svc list.
>>> >
>>> > Am I thinking about this the wrong way?
>>>
>>> Well, literally speaking it’s not an alternative; it’s the authority
>>> (the thing that alt-svc provides alternatives *to*).
>>>
>>
>> ​Yes, exactly. But since Alt-Svc lists alternatives, not authorities, it
>> doesn't make sense to think that the authority is implicitly in the
>> alternatives list.​
>>
>>
>> ​So if we're thinking about how to clear any alt-svc mappings that a
>> client might have stored, it seems perplexing to propose that be
>> accomplished by saying:
>>
>> Alt-Svc: <scheme>:<origin>​
>>
>> Further, consider the case of an https:// origin which uses ALPN to
>> optionally negotiate HTTP/2 but supports HTTP/1 for legacy clients. Does it
>> need to list both h2 and http1?
>>
>> Sure seems more explicit to say:
>>
>> Alt-Svc:
>>
>> It *is* in the list of “places I can get stuff for this origin from”,
>>> however.
>>>
>>
>> ​Agreed!
>>
>> ​Cheers,
>>
>> Ryan
>> ​
>>
>>
>