我有一个由IIS托管的express.js应用程序，根据文档中的最佳实践使用IISNode和URL重写规则。
是否存在endpoint /foo？q=1，它接受一个查询参数，并且对于每个GET请求，返回一个包含稍微不同的值的HTML主体（想象一个包含一个时间戳的HTML主体，该时间戳会为每个请求更新）。
暂时抛开HTTP GET的潜在“坏习惯”，因为“客户端控制之外”的东西而变化，我一直在努力找出为什么这个端点不为每个请求返回不同的结果，事实上，它工作得很好，独特的响应，对于前3-4个请求，然后突然开始为每个未来的请求返回完全相同的响应。（唯一改变这种行为的是，如果我改变查询参数的值，在这种情况下，对于特定的url和查询组合，它适用于3-4个请求，然后在最后一个响应上“锁定”。
为了进一步混淆和复杂化，这似乎只发生在Windows 2019服务器上，而不是Windows 2012服务器上。
1条答案
按热度按时间wa7juj8i1#
经过许多困惑之后，这被证明是IIS输出缓存的一个相对简单的问题。
从根本上说，如果您启用了输出缓存（用户或内核模式）并为 *.js配置了规则**，并且您的HTTP请求具有查询参数，则输出缓存将缓存所有**发往节点应用程序的请求。
这似乎是URL重写行为的结果，这意味着输出缓存似乎“作用”在节点入口点（通常是app.js）上。
实际上，这意味着对节点应用程序发出的每个请求都受到间歇性缓存的影响，除非您了解其根本原因，否则这将特别令人困惑！
此外，如果您只想选择性地缓存 *.css或 *.jpeg等，则可能会出现以下情况：文件来自你的节点应用程序，你不能这样做（因为所有的URL似乎都被视为.js，这是唯一的规则，永远适用，总是毯子。
我的希望是，这可以避免其他一些可怜的灵魂被IISNode、URL重写和Node.js的IIS OutputCaching的这种“表面上”令人惊讶的缓存行为所迷惑！