<div dir="ltr"><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">To add to Francis' answer, browsers might not respect server specification for expiration.<br><br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">must-revalidate however forces the browser to check the expiration of the resource before attempting of really load it again from the server.<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">Read: <a href="https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.4">https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.4</a><br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">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.<br><br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">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.<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">That is the standard behavior of nginx, though, you should not need special rules for it.<br></div><div class="gmail_extra"><div><div class="gmail_signature" data-smartmail="gmail_signature"><font size="1"><span style="color:rgb(102,102,102)">---<br></span><b><span style="color:rgb(102,102,102)">B. R.</span></b><span style="color:rgb(102,102,102)"></span></font></div></div>
<br><div class="gmail_quote">On Thu, Jun 30, 2016 at 2:51 PM, Francis Daly <span dir="ltr"><<a href="mailto:francis@daoine.org" target="_blank">francis@daoine.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, Jun 30, 2016 at 10:45:31AM +0200, Daniel Eschner wrote:<br>
<br>
Hi there,<br>
<br>
> i need to understand the caching options better. So, i have serval Questions ;)<br>
<br>
</span>I think in this mail, you refer to the caching done by your browser.<br>
<br>
That is entirely controlled by your browser; but it will probably respect<br>
the suggestions that the server makes.<br>
<br>
"A web page" is typically one request for some html, plus multiple<br>
requests for css, js, and image files.<br>
<br>
Each of those requests is independent, and each of the responses can be<br>
cached (or not) by your browser, as it sees fit.<br>
<span class=""><br>
> add_header Cache-Control public;<br>
> add_header Cache-Control must-revalidate;<br>
> expires 7d;<br>
<br>
</span>These lead to http response headers sent to the browser; how the browser<br>
handles them it entirely its business. Essentially the server is<br>
suggesting "do cache this, cache it for 7 days, and then check again".<br>
<br>
You can look at the actual http response headers received by your browser,<br>
and you can check its documentation for how it is expected to handle them.<br>
<br>
(It is possible that other response headers are sent which say "do not<br>
cache this".)<br>
<span class=""><br>
> 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.<br>
<br>
</span>"reload" is probably an instruction to your browser to fetch the (first,<br>
html) page again from outside its local cache.<br>
<br>
If you follow a link and then use your browser's "back" button, that<br>
can be an instruction to your browser to show the page again, from local<br>
cache if possible.<br>
<br>
Usually there is also an instruction available to your browser to invite<br>
it to fetch the page again, from the origin web server (bypassing or<br>
breaking through any intermediate caches).<br>
<br>
In any case, the multiple subsequent css, js, image requests may be<br>
handled from the local cache, or may be made to "the web", or may be<br>
made to the origin web server. Your browser decides what requests,<br>
if any, it will make.<br>
<span class=""><br>
> Is that a Browser issue or a nginx issue? Need to know where i have to search ;)<br>
<br>
</span>It seems like expected behaviour to me.<br>
<br>
It is initially a browser issue.<br>
<br>
If you can see a request that you think should not be made; and if you<br>
can see the previous response that you think should have been used instead;<br>
and if you can see a "please do not cache this" in that response; then you<br>
can check where in your nginx that "please do not cache this" came from.<br>
<span class=""><br>
> 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?<br>
<br>
</span>The server said "please cache this for 7 days".<br>
<br>
The browser may or may not have done that. Perhaps it never writes to<br>
disk; or clears the disk cache on startup, or something.<br>
<br>
Cheers,<br>
<br>
f<br>
<span class="HOEnZb"><font color="#888888">--<br>
Francis Daly <a href="mailto:francis@daoine.org">francis@daoine.org</a><br>
<br>
_______________________________________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" rel="noreferrer" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx</a></font></span></blockquote></div><br></div></div>