Subject: Re: How to reset ALTSVC

From: Bence Béky <[email-masked]>
Date: Wed, 1 Apr 2015 08:11:14 -0400

Hi Martin,

On Tue, Mar 31, 2015 at 6:22 PM, Martin Thomson
<[email-masked]> wrote:
> You could send a redirect-to-self value without changing the grammar
> too.  Or you could set the max-age to 0.  Or both.

I do agree with you that either of these could be agreed on as valid
ways to reset alternative services.  I don't particularily like them
from an implementation viewpoint.  The seft-redirect because if your
client implementation does not specifically prepare for this case, it
might end up racing two connections to the same server.  The second
option because if your client implementation does not specifically
prepare for this, it might treat the header as invalid if the max-age
is 0, or use its preferred default like one day, depending on the mood
of the implementer.  RFC 7234 Section 4.2.3 says about age that it's
"0, if not available", but this usage is not "not available", but
"special meaning: this is a valid alternative service with is a
placeholder for null alternative service".

I would not be terribly unhappy if concensus was to use one of these
hacks, but given these caveats, I believe it would still be necessary
to explicitly spell out this use in the specification.

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

And what if the header or frame contains two alternative services, one
of them the special value (identical to origin or having ma=0), the
other a valid alternative?  The empty list placeholder value is
ignored and makes previously discovered alternative services cleared,
but should the other alternative service one be dropped on the floor
or added to the list?  Or does it depend on the order?  Undefined?

Thanks,

Bence

---

From: Martin Thomson <[email-masked]>
Date: Wed, 1 Apr 2015 09:24:20 -0700

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

---

From: Ryan Hamilton <[email-masked]>
Date: Wed, 1 Apr 2015 16:02:54 -0700

> a validate alternative.  That it's implicit and always present isn't

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?

Cheers,

Ryan

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 2 Apr 2015 11:17:23 +1100

> 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:
> That's surprising to me. As I read the spec, Alt-Svc is all about specifying different ways to reach a server:
> 
> 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.
> 

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

It *is* in the list of “places I can get stuff for this origin from”, however.

Cheers,

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

---

From: Ryan Hamilton <[email-masked]>
Date: Wed, 1 Apr 2015 20:37:49 -0700

On Wed, Apr 1, 2015 at 5:17 PM, Mark Nottingham <[email-masked]> wrote:

> specifying different ways to reach a server:
> >
> 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
​