Re: How to reset ALTSVC

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
> ​
>
>