Re: Alt-Svc special value "clear" clarification

On Wed, Mar 29, 2017 at 5:42 AM, Samuel Hurst <samuelh@rd.bbc.co.uk> wrote:

> 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?
>
> The origin requests that all alternatives for that origin be invalidated.
alt1 and al2 are the alternatives.


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


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



>
> -Sam
>
>

Received on Wednesday, 29 March 2017 12:33:48 UTC