-
Notifications
You must be signed in to change notification settings - Fork 0
Revalidation is "EXPIRED" when there is no precondition #15
Comments
Related to #13, which I think is incorrect based on the spec and browser implementation :) |
So basically, i'm just missing a check for 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. |
I think this is incorrect. There's no way to revalidate if you don't have either a strong or weak validator, i.e: Even the Mozilla docs state:
|
@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
Then he goes on to explain what "must revalidate" actually is:
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 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 |
Ahhhh, well.. yeah! It's nice to have multiple pairs of eyes looking at this HTTP caching. Thanks for the link! |
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 |
Hi again,
When you hit the revalidation code, the following rules are applied:
https://github.com/aw/CacheRules/blob/master/lib/cache_rules.rb#L127-L133
Which internally calls:
https://github.com/aw/CacheRules/blob/master/lib/helpers.rb#L365-L369
Now I could not find such mandatory. This might be a design choice in your library, but I don't think a Gateway Timeout is appropriate for all cases here.
Let's consider the case of a simple
must-revalidate
request.Meaning, fresh for 60 seconds, MUST NOT use stale when it has expired. If requested past 16:41, it SHOULD just retry the request. In this case, because no
ETag
orLast-Modified
is present in the cached response, nor is there aIf-None-Match
in the request, it gives us a 504, but we have not even tried to reach the origin server.I think you implemented it as such because of https://tools.ietf.org/html/rfc7234#section-4.3.1 where it says
However, when you don't have these headers, you would not send a conditional request, but a regular one. This is how both Chrome and Firefox have implemented it. It is mentioned in the mozilla docs: It is either validated or fetched again.
Because of the careful wording in the RFC, and not using a capitalized MUST/SHOULD in this paragraph, I believe you must always try to revalidate in the flow, regardless of the presence of the preconditions. It becomes, semantically, a conditional request if one of the headers is present, but otherwise it's a regular fetch request (and will always return a non-304 result).
Posted the RFC entry just for ease. The other mentions are only "triggering" extra invalidation/rules, but nothing says anything about an ETag / Last-Modified being mandatory.
The text was updated successfully, but these errors were encountered: