Alt-Svc alternative cache invalidation (ext#16)

>From the issue:

In 3 The Alt-Svc HTTP Header Field, there's:

> When an Alt-Svc response header field is received from an origin, its value invalidates and  replaces all cached alternative services for that origin.

However, in several other places, we now say that multiple
alternatives can co-exist (with the client figuring out which to use).

Is this still our intent -- i.e., that the header field has a special
cache invalidation semantic -- or is it just left over from our
previous approach?

--

I think that this is residue from previous changes.  A small tweak can
fix it up.

The change regarding multiple services (i.e., clients choose which of
many it uses) is the right one.  However, that doesn't let a server
explicitly kill an Alt-Svc advertisement.  I think that this is useful
functionality.

I think that we should say that the tuple of (origin, service
protocol, service endpoint) is the key and that new advertisements
that match update the expiration time.

The only possible caveat is authentication of this information.  An
unsecured advertisement cannot override a value that has been set on a
secured channel.  Though thinking that through, I don't think that we
ever have a sometimes-secured/sometimes-not-secured origin in that
way.  There's an interaction with HTTP-TLS that we need to be careful
with.  I'll make a note.

Received on Monday, 18 August 2014 17:23:33 UTC