Revalidation is "EXPIRED" when there is no precondition about cacherules

[aw]

So basically, i'm just missing a check for must-revalidate in the Cache-Control header?

I appreciate the amount of detail you provide in your issues, but it confuses me even more. Can you just tell me what's the problem? Thanks.

[SleeplessByte]

@aw of course. This one confused me a lot as well.

The issue here is that you can not [re]validate without preconditions and we both agree on this and the docs do as well.

The directive "must-revalidate", I believe, means something different than the action "revalidate". The former means, as per the spec, you may not use a stale response and is must validate. Now, when it can't send a conditional request (no if-none-match / if-not-modified since), implementors actually fetch, instead of 504. Therefore I think that the following from Jake Archibald is correct:

First he talks about the wording. You have actually implemented no-cache, no-store as he describes:

Note: no-cache doesn't mean "don't cache", it means it must check (or "revalidate" as it calls 
it) with the server before using the cached resource. no-store tells the browser not to cache it 
at all. Also must-revalidate doesn't mean "must revalidate", it means the local resource can 
be used if it's younger than the provided max-age, otherwise it must revalidate. Yeah. I know.

Then he goes on to explain what "must revalidate" actually is:

In this pattern you can add an ETag (a version ID of your choosing) or Last-Modified date header
to the response. Next time the client fetches the resource, it echoes the value for the content
it already has via If-None-Match and If-Modified-Since respectively, allowing the server to say
"Just use what you've already got, it's up to date", or as it spells it, "HTTP 304".

If sending ETag/Last-Modified isn't possible, the server always sends the full content.

https://jakearchibald.com/2016/caching-best-practices/

Note the can and not must, as well as the final line, which is exactly how Chromium, Mozilla handle it. If it finds must-revalidate and it doesn't have a precondition, it doesn't return 504. It just acts as if it was not cached at all.

Then we get back to your final statement: it only occurs provided a validator. This is then true. It does a "GET" to the origin otherwise. Therefore I propose to always make that request, as a GET, adding the preconditions, when you can (switching to a HEAD if you'd like, but this is just an optimization of course :)).

[SleeplessByte]

tbh I think you did a stellar job. It's much easier to look for discrepancies than figuring out a proper implementation.

That said, I'll keep going :p

[SleeplessByte]

Related to #13, which I think is incorrect based on the spec and browser implementation :)

[aw]

I believe you must always try to revalidate in the flow, regardless of the presence of the preconditions

I think this is incorrect. There's no way to revalidate if you don't have either a strong or weak validator, i.e: If-None-Match, ETag, or Last-Modified. How can the server return a cached response if there's nothing to revalidate from? It's missing information. I think this applies even if must-revalidate is supplied when there's no strong/weak validator.

Even the Mozilla docs state:

"Validation can only occur if the server provided either a strong validator or a weak validator."

[aw]

@SleeplessByte

The directive "must-revalidate", I believe, means something different than the action "revalidate"

Ahhhh, well.. yeah! It's nice to have multiple pairs of eyes looking at this HTTP caching. Thanks for the link!