Original text:
corresponding to the other keys could be returned, or the request could be forwarded towards the origin.  5. Origin servers that wish to take advantage of Variants will need to

Reviewer comments:
I've also added examples of the new behavior. This is an attempt to
URL shows an example of an origin server that contains English, French, and German versions of a resource, a cache that has cached the English and French versions, a request that asks for German or Spanish, and, I believe, permission in the spec for the cache to return the English version instead of asking the origin server for the German version. This happens because URL appends the first Variant to the list of requested languages even if the list of requested languages overlaps with the available variants. Is this a mistake in the algorithm, or intentional for some reason?
The language algorithm does that so that an origin can denote a 'default' language -- i.e., what to serve if there isn't any overlap between the client's preferences and what's available. For example, if a user configures their browser to send and the page is only available in English and French, there needs to be a way to say "send English by default." I don't know of any use case where someone would want to serve a hard error when the language doesn't match, but if that's in scope, we could figure something out. If you're looking for something more deterministic in caches (here, the distinction between "these ar the responses that are available and preferred" and "here's the default" is blurred), I'm interested. P.S. in that diff, the line with the comment "prefers French, will accept English(?)" seems wrong.
I think establishes the default language without confusing it with the responses that are available and preferred. I am also not interested in a hard error when the language doesn't match. And thanks, I've fixed the example.
I'm not entirely happy with the optionality of behaviour on the cache's part with those MAYs. The most explicit thing we could do would be to break this information out into a separate header (e.g., ), but sticking with the current syntax for the moment, what if we had special values that, when occurring in that first slot, indicate that the default should NOT match? E.g., where does the magic.
I'm personally happy with turning those MAYs into MUSTs. They're MAYs because that's what was in the older RFCs, but I agree that I don't like making things optional. If I do this in my update tomorrow morning, do you still want to explore the token? I don't really like it because it seems like always the wrong thing for a client to send. I also don't see a particular need to pull the defaults out to a separate header.
I'm a bit interested in , but not adamant. I think it'd be fine if they flipped to MUST as long as the implications were noted.

Revised text:
corresponding to the other keys could be returned, or the request could be forwarded towards the origin. <ins> 4.3.1. If the selected variants-header was: And a request comes in with the following headers: Then sorted-variants in cache is: If the cache contains responses with the following Variant-Keys: Then the cache needs to forward the request to the origin server, since Variants indicates that "de" is available, and that is acceptable to the client. 4.3.2. If the selected variants-header was: And a request comes in with the following headers: Then sorted-variants in cache are: This allows the cache to return a "Variant-Key: en" response even though it's not in the set the client prefers. </ins> 5. Origin servers that wish to take advantage of Variants will need to