Dan*_*ing 6 http cache-control
我不明白must-understandHTTPCache-Control标头的指令。有哪些示例说明何时使用此功能，以及服务器可能使用缓存可能理解或不理解的哪种状态代码？
响应
must-understand指令指示缓存仅在根据状态代码了解缓存要求时才应存储响应。
must-understandno-store应该与后备行为结合起来。Run Code Online (Sandbox Code Playgroud)Cache-Control: must-understand, no-store如果缓存不支持
must-understand，它将被忽略。如果no-store也存在，则不存储响应。如果缓存支持
must-understand，它会根据其状态代码来存储响应并了解缓存要求。
RFC 9111中也对其进行了正式描述：
必须理解的响应指令将响应的缓存限制为能够理解并符合该响应状态代码要求的缓存。
包含必须理解指令的响应还应该包含 no-store 指令。当实现“必须理解”指令的缓存收到包含该指令的响应时，如果缓存理解并实现了状态代码的缓存要求，则它应该忽略“无存储”指令。
尽管有这些描述，我仍然不知道该指令在什么情况下有用。
在这里找到了对该指令的基本原理的很好解释，包括must-understand用例（它是日语的，所以您可能需要翻译）。在该页面的末尾，有一个对HTTP 工作组 re: 的票证/讨论的引用。must-understand
总结一下两者：
Cache-Control: must-understand，则缓存不得存储响应，除非它理解并实现状态代码的相关语义。当引入新的状态代码时，情况会发生怎样的变化：
Cache-Control: must-understand，服务器可以显式指定仅当缓存支持状态代码的语义时才应缓存响应。导致引入该指令的问题可以在 github 上must-understand找到。现状是任何最终（非 1XX）状态都可以被缓存，并且缓存实现将缓存状态默认定义为可缓存或使用缓存标头发送的任何响应。但是，某些状态确实需要一些额外的处理（尤其是 206 和 304），某些状态永远不应该被缓存（例如 421 或 502）。
\n\n[\xe2\x80\xa6] 部署的实现会以明确的新鲜度缓存响应，即使不了解状态代码。
\n
\n\n我们在这里试图解决的问题是，许多缓存的部署周期很长，让它们根据指定的状态代码列表而不是协议内信号来调整其行为并不是很好。
\n[\xe2\x80\xa6]
\n206 Partial Content如果其中的缓存指令不适用于其内发生的响应，则具有类似操作的新状态代码将被错误缓存。即使我们想在将来引入一个新的类似部分响应状态（不太可能），我们也只需要让这些响应包含这个 [提议
\nmust-understand] 缓存控制指令，以显式将该响应标记为不同。
因此，他们引入这一点只是为了向前兼容的目的，以处理新状态代码的定义。不再有（或永远不会有）异常列表，而是明确地保留旧行为：
\n\n\n新的最终状态代码的定义应该指定它是否可以启发式缓存[以前：默认情况下可缓存]。请注意，如果响应具有明确的新鲜度信息，则可以缓存任何具有最终状态代码的响应。定义为启发式可缓存的状态代码允许在没有显式新鲜度信息的情况下进行缓存。同样，如果使用必须理解的缓存指令，状态代码的定义可以对缓存行为施加约束。
\n
我无法给出这种新状态代码的示例。希望它们永远不会存在并定义奇异的缓存要求。再次引用马克·诺丁汉的话：
\n\n\n我对此的反应是，我们不应该设计新的机制，比如严重干扰 HTTP 的部分内容；我们应该这样做。我希望我们现在已经了解到它们效果不佳。
\n
但你永远不知道。此外，仅此指令的存在就允许缓存实现决定它们将缓存具有未知状态代码的响应，而不必担心将来会中断。这简化了新状态代码的引入，具有正常的缓存语义，并确保它们从一开始就得到正确的缓存，而无需更新 Web 基础设施。
\n| 归档时间： |
|
| 查看次数： |
162 次 |
| 最近记录： |