【问题标题】:Are both "Cache request directives" and "Cache response directives" needed?是否需要“缓存请求指令”和“缓存响应指令”?
【发布时间】:2018-02-10 17:00:18
【问题描述】:

如果我已经有了“缓存请求指令”,那么“缓存响应指令”有什么意义。他们有没有添加任何东西?如果没有它们,我的应用程序会运行相同吗?

我正在寻找“缓存响应指令”是否多余的证据。如果它们是多余的,我不会理会它们。

GC_

【问题讨论】:

  • 你能解释一下什么是“缓存请求指令”和“缓存响应指令”吗?你的意思是Cache-Control 标头吗?
  • @shaochuancs 是的,Cache-Control 在响应和请求中。
  • 简短的回答是:是的,它们都是必需的。即使您已经有Cache-Control 的请求,Cache-Control 的响应也不是多余的。它们是两个不同的东西:Cache-Control 作为响应,从服务器的角度定义了各种资源的缓存策略。请求中的Cache-Control 定义了需要调整缓存策略的例外情况。我会做一些调查,查阅相关知识并尝试提供答案(如果没有出现好的答案)。
  • 你在开发 HTTP 缓存吗?
  • @Rei 不。我正在帮助编写应用程序的前端和服务器应用程序。

标签: http caching web http-headers


【解决方案1】:

我假设您是作为应用程序开发人员询问的,如果是这样,您不应该为应用程序在请求中收到的任何 Cache-Control 标头而烦恼。

为什么? 因为该 Cache-Control 标头用于在请求到达您的应用程序之前进行缓存。 它不适用于您的应用程序。

RFC7234 Section 5.2 对此进行了解释(强调我的):

“Cache-Control”标头字段用于为请求/响应链中的缓存指定指令。

标头的目的是告诉缓存如何处理请求。 您的应用程序收到标头,因为它附加到请求。 但仅仅因为你收到了它,并不意味着它是给你的。

底线:忽略请求中的任何 Cache-Control 标头。

响应中的 Cache-Control 来自您的应用程序,它也适用于缓存。 您使用它来告诉缓存如何处理响应。 基本上,您使用标头来指定响应是否可缓存以及如果可以缓存多长时间。 它不仅仅是请求中收到的 Cache-Control 标头的副本。

他们添加了什么吗?

是的,他们有。 响应中的 Cache-Control 告诉缓存响应是否可缓存,如果是, 它允许缓存通过缓存响应立即提供等效请求。 从客户端的角度来看,这可以减少应用程序的负载并缩短响应时间。

RFC7234 Section 4.2 状态:

当一个响应在缓存中是“新鲜的”时,可以在不联系源站的情况下满足后续请求,从而提高效率。

你的下一个问题:

如果没有它们,我的应用程序会运行同样的方法吗?

这取决于。 如果您的应用程序没有为不得缓存的响应添加适当的 Cache-Control 标头,则未来的请求可能会收到陈旧的响应。 因此,我建议至少将Cache-Control: no-cache 添加到不得缓存的响应中。

在评论部分对您的问题进行补充说明

标头通常应该来自您的后端,而不是您的前端。 这允许缓存准确地加速对后端的请求并保持前端请求代码简单。 有一个例外:如果后端不是您的,并且其响应新鲜度政策不符合您的要求。

可能需要一个示例场景:

假设,除了向您自己的后端发送请求外,您的前端还会向其他人的后端发送请求。 这个特定的后端通过发送 Cache-Control: max-age=300 或适当的 Expires 标头指定其响应最多可缓存 5 分钟。

假设您希望响应的陈旧时间不超过 10 秒,因为 5 分钟对您来说太陈旧了。

由于后端不是您的,您无法更改 5-minutes 指令,但您可以使用 Cache-Control: max-age=10 发送请求,从而强制缓存获取新的响应,如果尽管后端有 5-minutes 指令,但缓存的响应已超过 10 秒。

这是从您的前端发送 Cache-Control 标头的适当情况:后端不是您的,并且其响应新鲜度策略不符合您的要求。

【讨论】:

  • 丽,谢谢。前端是否应该在请求头中发送缓存控制?
  • 就我而言,我会同时控制请求和响应标头。
  • @GC_ 不,不应该,除非后端不是您的,并且其响应新鲜度政策不符合您的要求。我会更新我的答案以获得解释。
【解决方案2】:

是否需要“缓存请求指令”和“缓存响应指令”?

是的。请求标头中的Cache-Control 和响应标头中的Cache-Control 都需要。即使您已经在请求标头中有Cache-Control,响应中的Cache-Control 也不是多余的。它们是两种不同的东西。根据RFC7234

缓存指令是单向的,因为请求中存在指令并不意味着响应中将给出相同的指令。

一般来说,响应头中的Cache-Control从资源提供者的角度控制缓存行为。 -- 资源是否应该存储在缓存中?有效期多久?如有要求,是否需要重新验证?等。由于可以为所有 HTTP 请求配置响应标头,“缓存响应指令”提供了一种为所有资源定义缓存策略的方法。

Cache-Control在请求头中,但是,从资源消费者的角度控制缓存行为。这更像是定义特殊情况,需要调整特定资源的缓存策略。如果检查RFC7234,大多数“请求缓存控制指令”indicates that the client is willing to...indicates that the client is unwilling to...

此外,由于请求标头只能在某些情况下配置(例如 Ajax),因此许多 HTTP 请求不存在“缓存请求指令”。比如HTML文件解析后,会创建很多HTTP请求来获取静态资源(图片文件、css文件等),程序中无法手动为这些请求配置Cache-Control header。

如果我已经有了“缓存请求指令”,那么“缓存响应指令”有什么意义?

如果你只有“缓存请求指令”并且从来没有得到Cache-Control响应头,就会出现一些问题:

  1. 没有Cache-Control响应头,所有资源的缓存行为由浏览器决定(例如通过LM-Factor算法计算有效时间)。在最坏的情况下,根本没有缓存。
  2. 对于静态资源(如图片文件、css文件),由于不能在请求中配置Cache-Control,所以失去了对缓存的控制能力。

【讨论】:

  • 对不起,我给了他奖金。我也喜欢你的回答。希望我能以某种方式拆分它。
猜你喜欢
  • 2017-11-12
  • 1970-01-01
  • 2014-04-19
  • 2020-10-06
  • 1970-01-01
  • 1970-01-01
  • 2011-02-16
  • 1970-01-01
  • 2011-02-26
相关资源
最近更新 更多