Forum Home
Press F1
Thread ID: 111543	2010-08-01 08:46:00	If sites cacheing is set to the epoch date will images etc still cache	Morgenmuffel (187)	Press F1

Post ID	Timestamp	Content	User
1123714	2010-08-01 08:46:00	Hi all been playing with the live headers extension for firefox (wish there was an opera version), and I noticed that one of my sites had the sites expire date set as "Thu, 19 Nov 1981 08:52:00 GMT" now I know this is to stop cacheing, but does this mean that the images etc aren't being cached?	Morgenmuffel (187)
1123715	2010-08-01 10:24:00	You'll need to be a bit more specific about where exactly that date is set. There's no such thing as a 'site-wide expiry date', each resource will have its own headers (usually Cache-Control, Pragma and / or Expires) for managing client-side and proxy caching of that specific resource. If the appropriate headers are missing on a resource, then the default rules for whichever system is doing the caching (e.g. your ISP's transparent proxy, your browser's local cache etc) will apply. If you wish to change the default caching policy for images on a site, you will need to send the appropriate headers with every request for every image.	Erayd (23)
1123716	2010-08-01 11:50:00	How do i find the expires headers for the images then? or at least what the default is for example this site here nigel.geek.nz how do i tell what the expires caching setting on the images are	Morgenmuffel (187)
1123717	2010-08-01 16:27:00	...been playing with the live headers extension for firefox (wish there was an opera version)...There is - take a look at the 'Network' tab of Opera Dragonfly (Tools>>Advanced>>Developer Tools). You can see and investigate all the headers in there. ...had the sites expire date set as "Thu, 19 Nov 1981 08:52:00 GMT"...That's not the epoch date - the standard UNIX epoch is Jan 1st, 1970, 00:00:00 UTC. How do i find... what the default is?You can't. The default isn't a server setting, it depends on the user's browser settings, the ISP's cache settings, the settings on any reverse proxies your host may be using, etc etc. As a general rule, assume that anything you haven't explicitly set cache rules for will be cached indefinitely by something outside of your control, somewhere between your host and the client (or on the client itself). How do i tell what the expires caching setting on the images are?Unless you've set it somewhere, you'll need to issue a request to the webserver for the actual image, and watch the result. There are several ways to do this: Use some kind of header-sniffing tool. Use a browser-based debugger that can log or display the headers. Access the image (or the entire site) in a browser, and use something like wireshark to sniff the traffic. Use tcpdump or similar, and pipe the result through strings, then grep. Manually issue HEAD requests using something like netcat or telnet. I personally recommend the last option, unless you already have a tool you know and love for investigating headers. Generally, you'd do something like the following: erayd@amunet ~ $ nc nigel.geek.nz 80 nc: using stream socket HEAD /sbo_shop/includes/templates/classic/images/logo.gif HTTP/1.1 Host: nigel.geek.nz HTTP/1.1 200 OK Date: Sun, 01 Aug 2010 15:11:34 GMT Server: Apache/2.2.14 (Unix) mod_ssl/2.2.14 OpenSSL/0.9.8e-fips-rhel5 DAV/2 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 Last-Modified: Fri, 02 Jul 2010 22:10:47 GMT ETag: "3b0bd2-8b3-48a6edbe387c0" Accept-Ranges: bytes Content-Length: 2227 Content-Type: image/gif As you can see, that particular image has Date and Last-Modified headers (which help various bits of caching logic along the way figure out what to do with it based on its age), but doesn't have any kind of cache-control applied to it. Noting that the filetype is a gif image, there is no query string present, and the request method isn't POST, most caches will use the following logic for this file: If we don't already have the file, get the file, and add it to the cache. If we do have the file, and we got it or checked its status recently (note that 'recently' varies depending on the filetype and the specific app doing the caching, and sometimes means 'ever'), then fetch it from the cache and don't bother asking the webserver for it. If we didn't get or check it recently, issue a HEAD request to the webserver to figure out if we need to fetch it again. If the Last-Modified date hasn't changed, and the Content-Length matches the cached file size, fetch it from the cache. If the Last-Modified date is more recent than the timestamp on the file in the cache, or the file size doesn't match, issue a GET request to the webserver (i.e. fetch the file from the server). Is this what you wanted to know?	Erayd (23)
1