Understanding caching

[B.R.]

To add to Francis' answer, browsers might not respect server specification
for expiration.

must-revalidate however forces the browser to check the expiration of the
resource before attempting of really load it again from the server.
Read: https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.4
When the browser contacts server with the right version the resource in its
local cache already, the request is replied with a 304, which you might see
in you requests log in you browser console.

The probable scenario you will notice is: the base resource (webpage) will
be downloaded again (200) because there is a user action requesting it.
However, you should see the other included resources, typically small ones
like pictures, stylesheets, are only revalidated and are replied 304.
That is the standard behavior of nginx, though, you should not need special
rules for it.
---
*B. R.*

On Thu, Jun 30, 2016 at 2:51 PM, Francis Daly <francis at daoine.org> wrote:

> On Thu, Jun 30, 2016 at 10:45:31AM +0200, Daniel Eschner wrote:
>
> Hi there,
>
> > i need to understand the caching options better. So, i have serval
> Questions ;)
>
> I think in this mail, you refer to the caching done by your browser.
>
> That is entirely controlled by your browser; but it will probably respect
> the suggestions that the server makes.
>
> "A web page" is typically one request for some html, plus multiple
> requests for css, js, and image files.
>
> Each of those requests is independent, and each of the responses can be
> cached (or not) by your browser, as it sees fit.
>
> >                 add_header        Cache-Control public;
> >                 add_header        Cache-Control must-revalidate;
> >                 expires           7d;
>
> These lead to http response headers sent to the browser; how the browser
> handles them it entirely its business. Essentially the server is
> suggesting "do cache this, cache it for 7 days, and then check again".
>
> You can look at the actual http response headers received by your browser,
> and you can check its documentation for how it is expected to handle them.
>
> (It is possible that other response headers are sent which say "do not
> cache this".)
>
> > No when i browser arround Chrome said „From cache“ that works fine for
> me but when i reload the Website it seems that only *.JPGs comming from the
> cache.
>
> "reload" is probably an instruction to your browser to fetch the (first,
> html) page again from outside its local cache.
>
> If you follow a link and then use your browser's "back" button, that
> can be an instruction to your browser to show the page again, from local
> cache if possible.
>
> Usually there is also an instruction available to your browser to invite
> it to fetch the page again, from the origin web server (bypassing or
> breaking through any intermediate caches).
>
> In any case, the multiple subsequent css, js, image requests may be
> handled from the local cache, or may be made to "the web", or may be
> made to the origin web server. Your browser decides what requests,
> if any, it will make.
>
> > Is that a Browser issue or a nginx issue? Need to know where i have to
> search ;)
>
> It seems like expected behaviour to me.
>
> It is initially a browser issue.
>
> If you can see a request that you think should not be made; and if you
> can see the previous response that you think should have been used instead;
> and if you can see a "please do not cache this" in that response; then you
> can check where in your nginx that "please do not cache this" came from.
>
> > Closing the browser and start again it dont came from cache - but as i
> understand i say it will expire in 7 Days - so why nit not comming from
> local cache?
>
> The server said "please cache this for 7 days".
>
> The browser may or may not have done that. Perhaps it never writes to
> disk; or clears the disk cache on startup, or something.
>
> Cheers,
>
>         f
> --
> Francis Daly        francis at daoine.org
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20160630/cf772302/attachment.html>