Subject: How to reset ALTSVC

From: Bence Béky <[email-masked]>
Date: Tue, 31 Mar 2015 16:51:54 -0400

Hi,

I would like to be able to construct HTTP/1.1 Alt-Svc headers and HTTP/2
ALTSVC frames that indicate that the client should forget all previously
discovered alternative services for that given origin.  (With the caveat
from the earlier "Alt-Svc alternative cache invalidation (ext#16)" thread
that they would only invalidate alternative services that came from the
same discovery mechanism.)  The most obvious way would be to send an
Alt-Svc header field with an empty value, or an HTTP/2 ALTSVC frame with an
empty Alt-Svc-Field-Value.  However, the current draft
<https://tools.ietf.org/id/draft-ietf-httpbis-alt-svc-06.html> calls for at
least one alternative in Section 3, and a mandatory Alt-Svc-Field-Value
field in Section 4.  I propose to allow zero alternatives like this:

Alt-Svc = *( alternative *( OWS ";" OWS parameter ) )

and to make Alt-Svc-Field-Value optional.

Here is an example use case: the client visits foo.com and gets an Alt-Svc
header field or ALTSVC frame pointing to bar.com.  Later bar.com goes down
for maintenance.  When the client visits foo.com the second time, it turns
to foo.com only.  (Either because it happens to have a connection open to
foo.com for another service, or because it observes the probability
parameter of alternative services and the coin flip went that way, or it
has foo.com's IP address cached, or for any other reason.)  At this time,
bar.com is down, and foo.com would really love to tell the client about
it.  But it cannot, and the third time the client tries to connect to
bar.com (for whatever reason), and wastes the user's time waiting for a
connection that will never go through.

Or even if the client tries to connect to both foo.com and bar.com at the
same time, if it happens to be that bar.com is a live server but no longer
providing service for foo.com (which the client will discover after the TLS
handshake when seeing that the certificate is not valid for foo.com), then
resources are wasted on both the client and bar.com.  During the previous
request to foo.com, the server could have told the client about that.

Thank you,

Bence

---

From: Martin Thomson <[email-masked]>
Date: Tue, 31 Mar 2015 15:22:40 -0700

On 31 March 2015 at 13:51, Bence Béky <[email-masked]> wrote:
> that they would only invalidate alternative services that came from the same
> discovery mechanism.)  The most obvious way would be to send an Alt-Svc
> header field with an empty value, or an HTTP/2 ALTSVC frame with an empty
> Alt-Svc-Field-Value.  However, the current draft calls for at least one
> alternative in Section 3, and a mandatory Alt-Svc-Field-Value field in
> Section 4.  I propose to allow zero alternatives like this:
>

You could send a redirect-to-self value without changing the grammar
too.  Or you could set the max-age to 0.  Or both.

---

From: Ryan Hamilton <[email-masked]>
Date: Tue, 31 Mar 2015 20:17:13 -0700

On Tue, Mar 31, 2015 at 3:22 PM, Martin Thomson <[email-masked]>
wrote:

> same
> too.

​Perhaps I'm not familiar enough with the spec, but what is
"redirect-to-self"?​

Or you could set the max-age to 0.  Or both.

Yeah, that's definitely an option, but it seems like a bit of a hack to me.​

​It seems like there should be an explicit mechanism to tell a client to
forget whatever Alt-Svc entries it has. Using ma=0 still implies setting
*some* sort of alternative, but in this case there is no valid alternative
to be specified, I think.
​