Replies: 1 comment
-
That is indeed the correct way of doing this, and how we designed it to be used. We set a reasonable max age on objects simply to avoid the issue of cache-capable clients getting old data stuck in cache, since the appropriate behavior of an object with no cache control metadata is not well defined. Depending on the implementation, it can mean anything from "do not cache at all" to "cache forever". Neither is desirable so we offer a reasonably sane advisory value. Note that semantically in HTTP, the max-age/expires time does not necessarily mean that the data becomes invalid, but indicates to an intermediate cache that it should revalidate with the upstream server. It is still quite possible for an "expired" object to return a 304 on a conditional request, indicating that the old object is still valid and should be retained longer. |
Beta Was this translation helpful? Give feedback.
-
I have it setup where I do not bother making a request until after the Expire date that is returned in the endpoint headers. I also pass back the If-Modified-Since, to make sure I do not receive duplicate data. I wanted to make sure this was the correct way of doing this.
Also, when I look at the /Points and Station endpoints to get my station and forecast urls, they expire 24 hours later. Is it necessary to re-check for the station and Points info that soon? I thought those kinds of things would last much longer. Just making sure I'm understanding what's expected. Thanks
Beta Was this translation helpful? Give feedback.
All reactions