not sure where this magic number came from, but it really suprised me
default to NoMaxAge, not a magic number
A one-hour age on static files seems like a useful default to me, I don't see why we would want to change it. If a user has different needs, they can always change it themselves.
well its not useful if the files can change within an hour, which was my use case. At that point I don't just change it, I have to sit down and debug why things aren't working.
A friendlier default would be to use ETag. If someone wants high performance they should tweak the settings according to their setup, which we can't know ahead of time.
IMHO, debugging why something is not changing while it should (probably some cache somewhere) is a lot easier than debugging why something that should be cached is not (where should I change what?), so I prefer the current default as well.
BTW, that number was introduced by b66adea.
@meteficha what is wrong with ETag? This magic number is always incorrect (in my case too big, but in the case where you don't see a broken application it is too small), whereas ETag will always cache correctly, and caching can be made stronger from there on a per-application basis.
@gregwebs My cache knowledge is rusty, but I remember that putting an ETag still forces the browser to do a HEAD in order to find out if the resource has changed, is that correct?
BTW, you should be careful with the new fd caching that Kazu introduced on warp, a path that is requested every minute will give stale results AFAICS.
actually, rather than ETag, last-modified is a better default (it is early here, brain still warming up). Yes, they both require that a request be sent. Generally speaking max-age is the strongest caching possible. However, in the current setup, when a browser comes back after an hour not only will a request be sent, but also a response, so we can't say that this provides better caching for all use cases.
If a user wants the strongest caching possible, they should change the configuration according to their setup. Yesod's static subsite will still be automatically configured for it for example, because we know the use case.
Oh, I always forget that yesod-static won't use wai-static's default values. In that case, I actually don't really care about wai-static's defaults since I imagine that whoever is using wai-static directly knows what they're doing =). But, as you correctly noted, should the default remain as an hour of max-age, we should probably use ETag by default as well.
I'm fairly certain that my selection of 1 hour wasn't arbitrary, but was based on what other common servers do (see http://httpd.apache.org/docs/2.2/caching.html). Of course, "Apache does it" is not really a good excuse for anything.
I'm fine switching the default caching mechanism to ETag or last-modified. But I would like to keep some kind of caching headers included by default.
Thinking about it some more: I'm OK removing the max-age default for the file server.