Current time: 10-23-2014, 08:59 PM Hello There, Guest! (LoginRegister)

Post Reply 
 
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Etag/Last Modified - the numpty question I've always wanted to know.
01-27-2011, 02:42 AM
Post: #11
RE: Etag/Last Modified - the numpty question I've always wanted to know.
No one an idea?
Find all posts by this user
Quote this message in a reply
01-28-2011, 03:12 PM
Post: #12
RE: Etag/Last Modified - the numpty question I've always wanted to know.
I've always heard (askapache.com) that for static content (JS/CSS), it's best to set far futures headers by setting *both* cache-control and expires headers. And then unsetting *both* etags and last modified.

Anybody have any thoughts on this?

The idea is that it is supposed to prevent any request at all for the file if the file is already in the browser cache.
Find all posts by this user
Quote this message in a reply
01-31-2011, 05:24 AM
Post: #13
RE: Etag/Last Modified - the numpty question I've always wanted to know.
(01-28-2011 03:12 PM)Thompson Wrote:  I've always heard (askapache.com) that for static content (JS/CSS), it's best to set far futures headers by setting *both* cache-control and expires headers. And then unsetting *both* etags and last modified.

Anybody have any thoughts on this?

The idea is that it is supposed to prevent any request at all for the file if the file is already in the browser cache.

This is exactly what we do, also for images and binaries (jpg, gif, pdf, odf, doc). But I don't have any info about if this is a better strategy than 1 'strong' (eg Expires) and 1 'weak' (eg Last Modified)... :-(.
Find all posts by this user
Quote this message in a reply
02-03-2011, 11:38 AM (This post was last modified: 02-04-2011 08:33 AM by jesper_mortensen.)
Post: #14
RE: Etag/Last Modified - the numpty question I've always wanted to know.
(01-28-2011 03:12 PM)Thompson Wrote:  I've always heard (askapache.com) that for static content (JS/CSS), it's best to set far futures headers by setting *both* cache-control and expires headers. And then unsetting *both* etags and last modified.

Anybody have any thoughts on this?

Cache-Control is a "strong" caching header, in the sense that it's unconditional. When you instruct caches via the cache-control header, they are allowed to cache the content for the indicated time without checking back with you. Expires acts in the same way.

Cache-Control is a HTTP 1.1 header, and as such requires a HTTP 1.1 compliant cache. Expires is a HTTP 1.0 header.

Personally, I don't serve both HTTP 1.1 and 1.0 caching headers anymore, I exclusively use the HTTP 1.1 Cache-Control.

ETags and Last-Modified are not "weak" caching headers, they are conditional download / content headers. ETag is a header used for conditional downloads, with a clear meaning and pretty consistent implementations. Last-Modified is, well, the timestamp for when the content was last modified. But since it is timestamp-based, and quite old, you can find some inconsistent behavior when Last-Modified is used as the sole criteria for conditional downloading.

If you want to manage caching, and have something that is simple to reason about, then there are IMHO 2 good solutions:
  • Serve content with the HTTP 1.1 Cache-Control header as the only 'caching' header.
  • Serve content with both Cache-Control and Expires, with both headers indicating the exact same expiry time.
In both cases, removing ETag and Last-Modified just makes things a little simpler to reason about, especially if ancient and weird proxy caches are involved.

I base my suggestion of not using 304's in part on the following quote:
"Cache Updates:
Caches are required to be updated by the headers in 304 responses,[...]
In practice, updates were spotty; a lot of the time, the test suite couldn’t get the cache into a state where it could tell, but when it could, there were failures. As a result, it’s probably not a good idea to rely on 304 responses or HEAD requests to update headers; better to just send a 200 back with a whole new representation."

Mark Nottingham has a really good write-up on HTTP mechanisms for controlling caches here:
http://www.mnot.net/cache_docs/
Find all posts by this user
Quote this message in a reply
02-04-2011, 08:23 AM
Post: #15
RE: Etag/Last Modified - the numpty question I've always wanted to know.
Thanks for the great info. I now get the 'unconditional' and 'conditional' bit :-).

Some check questions:
- Etag is difficult to use with a multi-server config, right?
- is the setting Cache-control: public important?
- we use the Cache-control Max-age as an absolute value (600 seconds) instead of a relative value, next to a relative Expire setting. Can that be a problem? Should I fix that? It works well as far as I can see...
Find all posts by this user
Quote this message in a reply
02-04-2011, 05:08 PM
Post: #16
RE: Etag/Last Modified - the numpty question I've always wanted to know.
(02-04-2011 08:23 AM)Geebee Wrote:  Thanks for the great info. I now get the 'unconditional' and 'conditional' bit :-).

Some check questions:
- Etag is difficult to use with a multi-server config, right?

Well, not really. You would just have to change the standard configuration to drop the INode part of the Etag. But if you have your caching headers configured properly, I do not see a reason, why you should use Etags at all.

(02-04-2011 08:23 AM)Geebee Wrote:  - is the setting Cache-control: public important?

This header serves two purposes:
a) It allows a shared cache to store the object as well. As an example, AOL users coming to your site are using a shared cache, when using the built-in browser. So if AOL user A has visited your site, AOL caches are storing the object. If then AOL user B is visiting your site, the object would be served from the shared AOL cache, not from your site.
This might become a grey area, if it is "cookied" content. Some shared caches might decide not to store the asset if it is cookied. Others will.

b) It allows Firefox when using an SSL connection to store the object in the disk cache. If the header is missing, it would be stored in memory cache and purged, when the user closes Firefox.

(02-04-2011 08:23 AM)Geebee Wrote:  - we use the Cache-control Max-age as an absolute value (600 seconds) instead of a relative value, next to a relative Expire setting. Can that be a problem? Should I fix that? It works well as far as I can see...

Shouldn't be a problem. Especially, if I recall correctly, as according to the RFC, Cache-Control beats Expires. So if you have both, and the browser is talking HTTP1.1, the browser would simply ignore the Expires Header. If it is HTTP1.0, it would ignore the Cache-Control Header.
But 600 seconds seems rather short. Might be a good idea to start versioning your assets and have a much larger TTL like 1 year.
See also here:
Souders on Versioning

Hope that helps a bit!

Kind regards,
Markus
Find all posts by this user
Quote this message in a reply
02-04-2011, 06:23 PM
Post: #17
RE: Etag/Last Modified - the numpty question I've always wanted to know.
Markus, thanks. We only use 600 seconds for the .htm files. For all assets we use an expire of 1 year, and we use versioning for new ones.
Find all posts by this user
Quote this message in a reply
02-04-2011, 06:52 PM
Post: #18
RE: Etag/Last Modified - the numpty question I've always wanted to know.
Hi,

- Use Cache-Control with high values (far future) on static assets; do versioning in the file name (e.g. all-20110204.css)
- No need to then also send an Expires, but it you need/must, give it the same 'value' as the Cache-Control
- Cache-Control beats Expires
- Cache-Control:Public is important, for reasons @Jesper_Mortensen outlines
- Use Last-Modified (not ETags) to enable conditional requests.
If you do the far future Cache-Control thing right, you will see very few to no conditional requests, because people have the file either in cache (and then use from cache) or not (200 response).
But why not, for that very small chance, send the Last-Modified?
Find all posts by this user
Quote this message in a reply
02-05-2011, 01:58 AM
Post: #19
RE: Etag/Last Modified - the numpty question I've always wanted to know.
Ok, I think I have all headers covered now... Still have to let our tech-guys add 'cache-control public' and maybe 'last-modified' for those corner-cases if 'cache-control max-age' and 'expires' don't work :-).
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 1 Guest(s)