Check this picture: http://i54.tinypic.com/2gy7mrt.png
How to achieve that for my static files? I mean so the browser even wouldn't make a request to server, just take the file from cache.
On what static files should this method be used?
Assuming your server is Apache, have a look at mod_expire.
The static files I have configured to expire "later" are text/css, text/javascript, application/javascript and image/*.
Send 304 Not Modified header.
I would use it on anything that is unlikely to change often - your site's logo, sprite image, etc.
If you have sent far distant expiry headers, and then decided you need to change the asset, simply append a time stamp / release, e.g. sprites.png?4000.
Related
I am using Apache server with mod_expires enabled. I have setup headers so that static files expire a week later. File is request via jQuery.get() method, cache set to true.
However, when I refresh the page on browser (Firefox), it always requests the file again. Caching and header field values seem to have no effect.
Below is a screenshot from Firefox developer tools.
How did you come up with the If-None-Match value? I don't see an ETag header with that value. Server will always send you a new one.
Another thing note is browser reload behaviour. By asking a refresh you may be asking for an end to end reload which bypasses all the caches, afaik.
I sense I'm going to end up embarrassed for asking such a simple question, but I've been researching for days and can't any useful information.
What determines the HTTP response header that a server sends? If I control the server (if we need concreteness, let's say Apache), then what file can I edit to change the response header? For example, to set it to include Content-Length instead of Transfer-Encoding: chunked?
I'm aware that PHP and Java Servlets can be used to manipulate headers. The existence and content of response headers is fundamental to HTTP, though, so there ought to exist a way to edit these without using outside technology, no?
Certain headers are set automatically. They are part of the HTTP spec and the server takes care of them for you. That’s what a web server is for and why it differs from, say, an FTP server or a fileshare. For example Content-Length is easily calculated by the webserver and needs to be set so the server just does it.
Certain other headers are set based on config. Apache usually loads a main config file (often called httpd.conf or apache2.conf) but then, to save this file getting into a big unwieldy mess it often loads other files from within that. Those files are just text files with lines of configuration text to change behaviour of the server. Other web servers may use XML configuration files and may have a GUI to control the config (e.g. IIS)
So, for some of the headers, you might not explicitly set the header value but you basically configure the server and it then uses that config to figure out the appropriate headers to send. For example you can configure the server to gzip certain files (e.g. text files but not jpgs which are already compressed). In Apache this is handled by the mod_deflate module and the config options it gives you. Once the appropriate config is added to the server config, the server will do the necessarily processing (e.g. gzip the file or not depending on type) and then automatically add the headers. So an Apache module is basically something that changes how the server works and this may or may not the also set headers. Another example is for sending caching headers to tell the browser how long to cache files for. This is controlled by adding the mod_expiries module and all the config options it allows. While some of these headers could be hardcoded (e.g. Cache-Control) others depend on Apache doing calculations (e.g. Expires) so better to use the module to do this for you based on your config.
And finally you can explicitly set headers in your server (in Apache this is done using the mod_headers module). This is useful for new features added to browsers for example (e.g. HSTS, CSP or HPKP) where the server doesn't need to do anything but just add the header and the client (e.g. the web browser) knows what to do with them. You could add a JonahHuron header for example by adding this config to httpd.conf:
Header always set JonahHuron "Some Value"
As to whether that header is used depends entirely on the program receiving the response.
Edit: I found out my problem. I was using the network inspector wrong (in both Chrome and FF) -- basically I was clicking "refresh"
and watching the network inspector, but it would re-download
everything. What you need to do is go to the URL, then open the network inspector, then go to the URL
again ( Don't "refresh", just re-access the URL a second time). The
network inspector will notify you of which resources were pulled from
cache :)
Original question below:
I am trying to set the image cache settings in Apache. I have the following in .htaccess for 1 week image caching:
FileETag MTime Size
ExpiresActive On
<FilesMatch "\.(gif|jpg|jpeg|png)$">
ExpiresDefault A604800
</FilesMatch>
This looks correct when I check the network tab of the Firefox developer console, but I don't understand why the Request Header says "no-cache"
Note: I removed the lines that do not matter for this question.
I am also serving some images dynamically with PHP. I have caching for those images set for 2 days, but again, the response header says "no-cache". Is this anything to worry about? The images do not appear to be cached when I refresh Firefox. They look like they are being redownloaded:
Any help understanding these headers would be appreciated. If there is an easy way to determine if images are being pulled from cache or not, I'm not seeing it.
The Pragma and Cache-Control request headers mean the same thing, one's from HTTP 1.0 and the other is from 1.1. It's used to tell the server, or a proxy that does caching, that it wants fresh versions of the resource. It's NOT for telling the server that the browser won't cache, or that the browser won't be honoring the cache control the server responds with.
Ultimately, the server can tell a user agent "Here's the resource, cache it for 1 week", but it's still up to the user agent (e.g. browser) to honor that. It could always request the uncached version of the resoure every time instead of not sending the request and loading the locally cached copy.
I'm looking for an alternative to Amazon S3 for hosting static sites, but that allows GZIP compression depending on the Accept-Encoding header.
In other words, I'm looking for something that will return a different version of a file depending on the client's Accept-Encoding header. I don't mind uploading compressed and uncompressed files myself (it can be automated easily).
Besides that, the service needs to be capable of hosting websites (allows an index page and 404 page to be set). I don't need CNAME capabilities since I'll be using a CDN. I'd also like the capability to set caching headers (Expires, Last-Modified).
FYI, my startup, Site44, does static hosting by syncing with Dropbox. We support all of this except the customized caching headers, but we'd be open to that feature request. (Today we set the Cache-Control header using a heuristic based on the last modified date, with a maximum value of 24 hours.)
Rackspace Cloudfiles supports everything mentioned.
Using Apache with mod_rewrite, when I load a .css or .js file and view the HTTP headers, the Content-type is only set correctly the first time I load it - subsequent refreshes are missing Content-type altogether and it's creating some problems for me.
I can get around this by appending a random query string value to the end of each filename, eg. http://www.site.com/script.js?12345
However, I don't want to have to do that, since caching is good and all I want is for the Content-type to be present. I've tried using a RewriteRule to force the type but still didn't solve the problem. Any ideas?
Thanks, Brian
The answer depends on information you've not provided here, specifically where are you seeing these headers?
Unless it's from sniffing the network traffic between the browser and client, then you can't be sure if you are looking at a real request to the server or a request which has been satisfied from the cache. Indeed changing the URL as you describe is a very simple way to force a reload from the server rather than a load from the cache.
I don't think its as broken as you seem to. Fire up Wireshark and see for yourself - or just disable caching for these content types.
C.