Subject: Alt-Svc special value "clear" clarification

From: Samuel Hurst <[email-masked]>
Date: Wed, 29 Mar 2017 11:42:50 +0100

Hi all,

The HTTP Alternative Services RFC (7838) specifies that the "Alt-Svc"
header field can contain one of two values - either a list of
alternative services or the keyword "clear". From section 3 of the RFC:

> A field value containing the special value "clear" indicates that the
> origin requests all alternatives for that origin to be invalidated
> (including those specified in the same response, in case of an
> invalid reply containing both "clear" and alternative services).

My question is thus: What should the client do if an alternative service
returns an "Alt-Svc: clear" header? In particular, which endpoints
should be invalidated?

For example: The client makes a request to $origin, which in it's
response advertises alternative services $alt1 and $alt2. The client
then makes a subsequent request for $alt1, which then returns (either on
purpose or by accident) the "Alt-Svc: clear" header.

Given that $alt1 specified the clear and the RFC states that "all
alternatives" should be invalidated, and $origin is effectively an
alternative service for $alt1, should both $origin and $alt2 be
invalidated? Or should $alt1 and $alt2 be invalidated, even though
it was $alt1 that caused the action to be taken?

-Sam

---

From: Patrick McManus <[email-masked]>
Date: Wed, 29 Mar 2017 07:33:10 -0500

On Wed, Mar 29, 2017 at 5:42 AM, Samuel Hurst <[email-masked]> wrote:

> The origin requests that all alternatives for that origin be invalidated.
alt1 and al2 are the alternatives.

> purpose or by accident) the "Alt-Svc: clear" header.
There is only one origin - though you have named three servers for it.
clear requests that all alternatives for that origin to be invalidated.

It helps a lot to think of alt-svc asadditional DNS records for the origin.

> $origin is not effectively an altenative for $alt1. $alt1 isn't an origin
at all (it doesn't appear in a host header, for example).. the alternatives
are the servers that have been enumerated in the alt-svc header for the
origin in question. If the alternative service set is empty for any origin,
the usual http resolution rules still apply to reach it.

hth.

---

From: Samuel Hurst <[email-masked]>
Date: Wed, 29 Mar 2017 14:40:24 +0100

On 29/03/17 13:33, Patrick McManus wrote:
> $origin is not effectively an altenative for $alt1. $alt1 isn't an
> origin at all (it doesn't appear in a host header, for example).. the
> alternatives are the servers that have been enumerated in the alt-svc
> header for the origin in question. If the alternative service set is
> empty for any origin, the usual http resolution rules still apply to
> reach it.

Many thanks for the clarification. I'm not entirely sure why I thought
the origin was an alternative for the alternatives, that's probably
where I was getting confused the more I was trying to think about it.

Is it expected that the alternative services will include Alt-Svc
headers in their own responses? If they are providing exactly the same
service as the origin, would the advertised alternative services be
identical to those offered by the origin, i.e. including the alternative
service being used?

Best Regards,
Sam

---

From: Ryan Hamilton <[email-masked]>
Date: Wed, 29 Mar 2017 07:15:35 -0700

> identical to those offered by the origin, i.e. including the alternative

That's how I'm accustomed to seeing it deployed.​ Effectively, all the
servers which are configured to handle an origin are configured to respond
identically, just for simplicity. (But I can imagined others might do it
differently).

Cheers,

Ryan

---

From: Patrick McManus <[email-masked]>
Date: Wed, 29 Mar 2017 09:15:16 -0500

> identical to those offered by the origin, i.e. including the alternative

The alternatives *are* the origin just as much as the default-host origin
is. So whatever they choose to advertise has the same impact - including
clear, extending their own (self) alternative ttl via ma, etc..

now what they actually do is up to the implementation and whether it wants
to distribute these routing decisions (and therefore probably use short ma
that can be extended easily), or centralize them (let the alternatives
expire once in a while and have the default-origin make a new decision)..
both are reasonable approaches.