Alt-Svc alternative cache invalidation

[mnot]

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?

[mnot]

Discussed on-list. Cache invalidation is to be scoped to a specific discovery mechanism; e.g., the alternatives you discover via the response header will be invalidated when you see a new response header, while those that were discovered via the frame will be invalidated only when a new frame is received.

This means each mechanism needs to define its own exact invalidation semantics, and probably needs to be capable of carrying multiple alternatives.

[reschke]

For the header field we already say: "When an Alt-Svc response header field is received from an origin, its value invalidates and replaces all cached alternative services for that origin."

Just duplicate that in the description of the frame?

[mnot]

Almost. That existing text needs to be qualified to say that the response header invalidates previous services discovered via the response header, and then the section on the frame needs to say that it invalidates previous alt services discovered via a frame.

[reschke]

That sounds a bit like the client might have to maintain two sets; is that really true?

[mnot]

That's what we discussed on list.

[reschke]

I looked at the email thread, and it seems the use case mentioned was 1.1 --> op-sec --> 2 and then alt-svc being used for load balancing. In this particular case we'd indeed have one set received by header field and one set received by frame. But is relying on exactly these two sets sufficient? In particular, tying it just to the header field/frame distinction seems funky...

[martinthomson]

It's not the case that there are exactly two sets. It's the case that one source cannot override information acquired from another source, but it must override information from the same source.

[mnot]

Discussed in Prague; sense of room was to keep a single global scope for invalidation, to keep things simple. Need to adjust ABNF to allow an empty set. Add advice that server preference is expressed by lexical ordering.

[reschke]

I'm having second thoughts abound the "empty list" solution. In the past I've seen broken support for empty header field values (software components not being able to distinguish between "empty" and "not present").

[mnot]

I agree that that distinction is often a problem on server-side consumers (which span a large variety of implementations and quality thereof), but I'd suggest that it's less an issue in this case, given that a) the set of consuming clients is relatively smaller, and b) the party implementing the alt-svc behaviour presumably has control over the implementation, and can fix the bug if necessary.

[reschke]

I'm still uncomfortable with having a list-shaped header field value where the empty list carries a special meaning. How about allowing "Alt-Svc: clear" instead?

[mcmanus]

my instincts agree with Julian - empty headers with semantics are asking for trouble

[enygren]

Using "Alt-Svc: clear" (which would just be "clear" in the ALTSVC frame) makes sense to me. I think the key thing here is to have a specified and well-defined mechanism.

[mnot]

WFM.

[reschke]

Note that the statement about invalidation is in Section 3.1 already, so it's not specific to the header field variant.

[reschke]

Re-opening because of https://lists.w3.org/Archives/Public/ietf-http-wg/2015JulSep/0322.html