Alt-Svc: alternatives assigned by alternatives

Thinking a bit more about Alt-Svc, I'd like to see more clarity around when and how it's OK to cache (and later use) an alternative service you discover.

Right now, there are two scenarios:

1) You get an alt-svc (frame or header) from an origin
2) You get an alt-svc (frame or header) from an alternative service

#1 is pretty straightforward.

#2 is implicitly allowed by the spec in one or two places, for very reasonable purposes; if you're doing load balancing (one of the primary use cases), you need to be able to shift traffic around more than once. Likewise, if you're using Alt-Svc for Opp-Sec, you might need to do some load balancing after that.

However, that implies that an alternative service can refresh itself, indefinitely. 

E.g., imagine an origin request to <https://example.com/> that bounces the client to (h2, other.example.net, 443) with a lifetime of 60s. 

After 50s, if the other.example.net sends an ALTSVC frame updating the alt-svc cache to point to itself for another 60s (or hour, or day, or year), is it OK with folks for the client to continue using other.example.net for the (https, example.com, 443) origin for that period of time, without contacting the original origin?

If so, no worries.

If not, I think we need to limit #2 in some fashion. What I'd propose is that when you learn about an alternative from an origin, its freshness lifetime cannot exceed the original provided by the origin. That is, in the scenario above, other.example.net would only be valid for the original 60s period, regardless of what it tried to update; it could redirect traffic to another alternative during that 60s window, but not beyond it.

I think that would work reasonably well with the use cases we have in mind;

a) for Opp-Sec, you'd use a fairly (to very) long lifetime for the initial upgrade, giving plenty of leeway for future load shifting, etc.

b) for load balancing, you'd probably have a fairly short lifetime, but you'd just be checking back with the origin each time load balancing happened, and you could always assign a longer initial lifetime if this was a concern.

What do people think?

Regardless, I'd like to see #2 more clearly stated in the spec.

Cheers,


--
Mark Nottingham   https://www.mnot.net/

Received on Tuesday, 19 August 2014 07:40:23 UTC