How does Image Cache works in Browser - image

How can I make my Image cached by browser and expire after particular period of time

There are several HTTP headers that you can use to effect changes to the content caching policies.
This one:
Cache-control: no-cache
instructs the browser not to cache the content at all.
This one:
Expires: Tue, 20 Mar 2024 02:00:00 GMT
instructs the browser to expire its cached copy by the given time.
This one:
ETag: ab10be20
instructs the browser to consider ab10be20 as a hash of the contents and only if the value changes upon subsequent requests should it need to download the new contents.
Note that all of these are effectively advisory only and there's no possible way to enforce the purging of caches remotely.

Related

How can I force browsers use expire (rather than etags/modification time)

I have a server serving static files with an expire of 1 year but my browsers still get the file and receive a 304 - not modified. I want to prevent the browser from even attempting the connection. I realize that that happens in several different setup (Ubuntu Linux) with Chrome and Firefox.
My test is as follows:
$ wget -S -O /dev/null http://trepalchi.it/static/img/logo-trepalchi-black.svg
--2016-03-14 19:56:14-- http://trepalchi.it/static/img/logo-trepalchi-black.svg
Risoluzione di trepalchi.it (trepalchi.it)... 213.136.85.40
Connessione a trepalchi.it (trepalchi.it)|213.136.85.40|:80... connesso.
Richiesta HTTP inviata, in attesa di risposta...
HTTP/1.1 200 OK
Server: nginx/1.2.1
Date: Mon, 14 Mar 2016 18:55:29 GMT
Content-Type: image/svg+xml
Content-Length: 25081
Last-Modified: Sun, 13 Mar 2016 23:03:53 GMT
Connection: keep-alive
Expires: Tue, 14 Mar 2017 18:55:29 GMT
Cache-Control: max-age=31536000
Cache-Control: public
Accept-Ranges: bytes
Lunghezza: 25081 (24K) [image/svg+xml]
Salvataggio in: "/dev/null"
100%[==================================================================================================================================================================>] 25.081 --.-K/s in 0,07s
2016-03-14 19:56:14 (328 KB/s) - "/dev/null" salvato [25081/25081]
That shows correctly providing expires and cache control (via nginx).
If I go to the browser and enable cache and open diagnostic tools, the first hit I notice a 200 return code, then I refresh the page (Control-r) and find a connection with 304 - not modified return code.
Inspecting firefox cache (about:cache) I found it with correct expire and clicking on the link in that page I was able to see it w/o hitting the remote server.
I also tested pages where the images are loaded from image tags (as opposed as directly called as in the example above).
All the letterature I read state that with such an expire the browser should not even try a connection. What's wrong? RFC 2616 states:
HTTP caching works best when caches can entirely avoid making requests
to the origin server. The primary mechanism for avoiding requests is
for an origin server to provide an explicit expiration time in the
future, indicating that a response MAY be used to satisfy subsequent
requests. In other words, a cache can return a fresh response without
first contacting the server.
Note another question addresses the problem of how 304 is generated, I just want to prevent the connection to be made
Sandro
Thanks

IE caching issue, EVEN if correctly configured

I make a GET request to www.mysite.com and in the header I receive:
Cache-Control no-cache, no-store, must-revalidate
Expires Thu, 01 Jan 1970 00:00:00 GMT
Pragma no-cache
Otherwise, I receive notification that some visitors do not see my site but an error occured last week and now fixed.
Seems the error has been cached in their browsers and it is not doing a new request.
Can this be possible?
I believe browsers (including IE) won't cache whole pages, and that DOM is reloaded after every request. This data is contained in the request after all.
Therefore, your visitors may still experience errors. Does your fix depends on resources like JS or CSS? In this case you may have caching issues.

default time for an image to expire

I pushed some changes to one of our images to web server, but I found it's not updated on IE and firefox web browsers due to browser caching, since I saw the browsers didn't even request for image from server.
I have two choice. One is to update the image file name and re-deploy. The other is to let our users' browsers think the image exipires.
I haven't set anything in header or in code, here is the response:
Content-Length 32042
Content-Type image/png
Last-Modified Wed, 09 Nov 2011 18:41:50 GMT
Accept-Ranges bytes
Server Microsoft-IIS/6.0
X-Powered-By ASP.NET
Date Fri, 09 Dec 2011 01:26:03 GMT
Connection keep-alive
So I am wondering how soon it can expire?
Ideally, if your last-modified time stamp changes, everything should take of by itself. You can set up cache-control http://blogs.msdn.com/b/rahulso/archive/2006/02/02/suppress-caching-of-certain-mime-types-like-gif-jpg-etc.aspx to avoid it.

How do I know if image from my site is getting cached by proxy servers?

The following is a http response header from a image on our company's website.
HTTP/1.1 200 OK
Content-Type: image/png
Last-Modified: Thu, 03 Dec 2009 15:51:57 GMT
Accept-Ranges: bytes
ETag: "1e61e38a3074ca1:0"
Date: Wed, 06 Jan 2010 22:06:23 GMT
Content-Length: 9140
Is there anyway to know if this image is publicly cacheable in some proxy server? The RFC definition seems to be ambiguous http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1 and http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.4.
Run RED on your URL and it'll tell you whether the response is cacheable, among other information.
The headers you show appear to be cacheable.
If you would like to control the caching behavior of correctly configured proxies and web browsers, you might investigate using the Cache-Control and Expires headers to gain additional control.
Here is a webpage I had bookmarked that has one person's opinion of how to intepret the specifications you list (plus some other ones):
http://www.web-caching.com/mnot_tutorial/how.html
If you need to guarantee that someone sees a completely new image each time (even with misconfigured devices between you and them), you may want to consider using a randomized or GUID value as part of the URL.
Here is a tutorial on setting headers for proxy caching. Be sure to read the part about setting cookies!

Why doesn't my expires headers make my files stay in cache?

I'm using valid expires and no-cache headers for my static files and they stay cached for as long as I keep browsing, but when I close my browser and use it back after a while I see the static files loading again, even when not refreshing with ctrl (+ shift) + r
I'm using Firefox, cache size set to 250MB and I don't let it remove any private or cached data.
Headers:
Accept-Ranges: bytes
Cache-Control: max-age=29030400, public
Content-Length: 142061
Content-Type: image/png
Date: Tue, 08 Dec 2009 19:18:43 GMT
Expires: Tue, 09 Nov 2010 19:18:43 GMT
Last-Modified: Sun, 18 Jan 2009 18:33:48 GMT
Server: Apache/2.2.14 (EL)
Which version of Firefox? Is the server sending Etags for the static files? You can view details about Firefox cache by going to the address about:cache and poking around. That will give you an idea of what Firefox is caching.
Update: After looking at your header tags, it seems as if the max-age value is set to a date that is way in the past and that is overriding the the value being set in the Expires header. See the HTTP 1.1 protocol definition at: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.3.
If a response includes both an Expires
header and a max-age directive, the
max-age directive overrides the
Expires header, even if the Expires
header is more restrictive. This rule
allows an origin server to provide,
for a given response, a longer
expiration time to an HTTP/1.1 (or
later) cache than to an HTTP/1.0
cache. This might be useful if certain
HTTP/1.0 caches improperly calculate
ages or expiration times, perhaps due
to desynchronized clocks.
You will have to modify your Cache-Control header being sent by the server.

Resources