You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Persistence of alternates across network changes #71
Alternates provided because of location (seattle.edge.net vs. sfc.edge.net) need to be cleared on network changes. (They’re probably direct pointers to individual nodes/datacenters.) Alternates provided because of capabilities (sni.edge.net as alternate of legacy.edge.net) shouldn’t be cleared on network changes, because they’re not location-dependent. (The names probably resolve to different IPs based on location at the DNS level, or they resolve to anycast addresses.)
Should there be a hint to the client that a particular alternate does/doesn’t need to be flushed on changes? Might impact the issues described in 9.2, but TLS should still mitigate without the flushing.
I think that flushing is the always-safe option. We can define extensions later if this turns out to be especially problematic (or the optimization that retention affords is especially attractive).
Activity
martinthomson commentedon May 28, 2015
I think that flushing is the always-safe option. We can define extensions later if this turns out to be especially problematic (or the optimization that retention affords is especially attractive).
mnot commentedon May 31, 2015
See also #2. It's not clear that flushing a alt-svc used for oppsec is the safest thing.
Add the "persist" flag; proposal for #71
mnot commentedon Jul 21, 2015
Discussed in Prague; add a parameter to do this now.
Add the "persist" flag; proposal for #71
Tune Mark's commit around "persist" (#71)