Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alt-Svc alternative cache invalidation #16

Closed
mnot opened this issue Aug 18, 2014 · 16 comments

Comments

Projects
None yet
5 participants
@mnot
Copy link
Member

commented Aug 18, 2014

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 mnot added alt-svc labels Aug 18, 2014

@mnot mnot added the editor-ready label Mar 17, 2015

@mnot

This comment has been minimized.

Copy link
Member Author

commented Mar 17, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Jul 20, 2015

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

This comment has been minimized.

Copy link
Member Author

commented Jul 20, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Jul 20, 2015

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

@mnot

This comment has been minimized.

Copy link
Member Author

commented Jul 20, 2015

That's what we discussed on list.

@reschke

This comment has been minimized.

Copy link
Contributor

commented Jul 20, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Jul 20, 2015

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

This comment has been minimized.

Copy link
Member Author

commented Jul 21, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Aug 14, 2015

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

This comment has been minimized.

Copy link
Member Author

commented Aug 19, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Aug 20, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Aug 20, 2015

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

@enygren

This comment has been minimized.

Copy link
Contributor

commented Aug 20, 2015

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

This comment has been minimized.

Copy link
Member Author

commented Aug 24, 2015

WFM.

@reschke

This comment has been minimized.

Copy link
Contributor

commented Aug 26, 2015

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

reschke added a commit that referenced this issue Aug 26, 2015

@reschke reschke closed this Aug 26, 2015

@reschke

This comment has been minimized.

Copy link
Contributor

commented Sep 19, 2015

@reschke reschke reopened this Sep 19, 2015

reschke added a commit that referenced this issue Sep 19, 2015

@reschke reschke closed this Sep 19, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.