Apache FilesMatch：如何仅匹配附加时间戳的资产
我刚刚写并回答了一个关于 apache FilesMatch 识别文件名的问题；请参阅此处 了解更多信息，但最重要的是 apache 无法识别资产上文件扩展名之后的任何内容，其中包括（附加的 Rails）时间戳，作为文件名的一部分。
这种情况很糟糕，因为我们的资产出于某种原因没有为缓存清除目的添加时间戳，因此像这样的一揽子匹配：
<FilesMatch "\.(ico|jpe?g|png|gif|js|css)$">
ExpiresActive On
ExpiresDefault "now plus 1 year"
</FilesMatch>
将匹配符合缓存清除条件的资产以及符合缓存清除条件的资产。不是。对于那些不这样做的人来说，这可能很糟糕。
那么，谁能告诉我如何仅在文件名后面带有 \?\d{10} 的情况下匹配资产？
I just wrote and answered a question regarding what apache FilesMatch recognizes as the filename; see Here for more on that, but the skinny is that apache does not recognize anything after the file extension, which includes the (rails appended) timestamp, on an asset as part of the filename.
That kind of sucks because we have assets that, for one reason or another, are not timestamped for cache-busting purposes, so a blanket match like this:
<FilesMatch "\.(ico|jpe?g|png|gif|js|css)$">
ExpiresActive On
ExpiresDefault "now plus 1 year"
</FilesMatch>
Is going to match both assets that are eligible for cache busting as well as those that are not. For those that are not, well, this can be bad.
So, can anybody tell me how to match assets only if they have a \?\d{10} following the filename?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我发现了一个并不理想的黑客方法，但鉴于其局限性，它会起作用。查看这两个网站的解决方案：
I found a hack that is not ideal, but given the limitations, will work. Check out these two sites for the solution: