default to NoMaxAge, not a magic number #111

Merged
merged 1 commit into from Dec 26, 2012

3 participants

@gregwebs
Yesod Web Framework member

not sure where this magic number came from, but it really suprised me

@snoyberg
Yesod Web Framework member

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.

@gregwebs
Yesod Web Framework member

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.

@meteficha
Yesod Web Framework member

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.

@meteficha
Yesod Web Framework member

BTW, that number was introduced by b66adea.

@gregwebs
Yesod Web Framework member

@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.

@meteficha
Yesod Web Framework member

@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.

@gregwebs
Yesod Web Framework member

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.

@meteficha
Yesod Web Framework member

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.

@snoyberg
Yesod Web Framework member

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.

@snoyberg
Yesod Web Framework member

Thinking about it some more: I'm OK removing the max-age default for the file server.

@snoyberg snoyberg merged commit 1071869 into master Dec 26, 2012
@gregwebs gregwebs deleted the no-max-age branch Dec 26, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment