How to reset ALTSVC

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