Caching, versioning, and CDNs about combres HOT 3 CLOSED

Thanks for reporting the issue and the detailed write up. I will certainly be pleased to merge when we have worked out a good solution. I have two questions regarding the proposed fix:

1. It addresses client-side caching, but not serve-side caching? Shouldn't the same guard be placed in this line to prevent Combres to cache the response?
2. On the other hand, isn't a 404 response a better option than disabling caching and returning the wrong content? How does that impact your deployment workflow?

Let me know what you think.

from combres.

1. Hmm, not sure. In our case we want it to cache because the initial combining takes a couple seconds and don't want the servers to be constantly churning on that. We will have multiple copies in the cache but the files will always be correct. If you are using a distributed cache I think this would cause a problem though, perhaps a switch in the config somewhere?
2. I would rather have the wrong styles than no styles, but maybe there is a case where that is preferred? Another configuration setting?

from combres.

1. Distributed cache or not, wouldn't not guarding server cache mean the server will cache the response under the new path? That means even after you deploy the new files to the server in question, they won't be used until the cache expires, the same problem you tried to avoid, no? So I'm in the opinion that if a server hasn't been updated with new files, it shouldn't try to cache new path at all, both client & server.
2. I was thinking of scripts as well. If the HTML/DOM has been changed, using an old script might cause expected behavior. At least a 404 indicates that the server isn't ready with new code yet and nobody's surprised about some unexpected behavior (and filing a bug report).

from combres.