Subject: Re: How to reset ALTSVC

From: Bence Béky <[email-masked]>
Date: Wed, 26 Aug 2015 17:06:52 -0400

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

> On Wed, Apr 1, 2015 at 5:17 PM, Mark Nottingham <[email-masked]> wrote:
>
>>
>> > On 2 Apr 2015, at 10:02 am, Ryan Hamilton <[email-masked]> wrote:
>> >
>> > On Wed, Apr 1, 2015 at 9:24 AM, Martin Thomson <
>> [email-masked]> wrote:
>> > On 1 April 2015 at 05:11, Bence Béky <[email-masked]> 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
> ​
>
>

---

From: Erik Nygren <[email-masked]>
Date: Wed, 26 Aug 2015 17:40:12 -0400

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

>>> Well, literally speaking it’s not an alternative; it’s the authority
>>> (the thing that alt-svc provides alternatives *to*).
>>>
>>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 26 Aug 2015 15:16:31 -0700

> Alt-Svc = clear / 1#alt-value

Yes, better.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 27 Aug 2015 07:07:22 +0200

On 2015-08-26 23:06, Bence Béky wrote:
> 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.

As the others pointed out, the concern was a) that there are software 
components that do not handle empty values properly, and b) a concern to 
overload the concept of an empty list.

I only finished the edits yesterday and was planning to send an email 
today :-)

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

It would, but we are constrained by the HTTP header field semantics. A 
header field value is either list-shaped or it is not. We can't choose 
based on the field contents.

Best regards, Julian

---

From: Bence Béky <[email-masked]>
Date: Sat, 29 Aug 2015 11:20:44 -0400

Hi,

> https://github.com/httpwg/http-extensions/issues/16

Thanks for the clarification.  I'm sorry I missed the discussion on GitHub.

> It would, but we are constrained by the HTTP header field semantics. A header field value is either list-shaped or it is not. We can't choose based on the field contents.

Okay, that makes sense, thank you for the explanation.  Bummer.

By the way, if I understand correctly, "Alt-Svc = clear,
syntactically-inv\"alid-alt-value" would need to be ignored entirely
because it contains an alt-value which does not conform to the
grammar.  However, chances are that there will be implementations that
ignore the second alt-value as soon as they parse "clear".  Probably
does not make much difference though.

Cheers,

Bence

---

From: Julian Reschke <[email-masked]>
Date: Sat, 29 Aug 2015 19:19:24 +0200

> Thanks for the clarification.  I'm sorry I missed the discussion on GitHub.

No need to. Discussion that is non-editorial is supposed to happen here.

> does not make much difference though.

Agreed.

Best regards, Julian