ChatGPT解决这个技术问题 Extra ChatGPT

Pragma 和 Cache-Control 标头之间的区别?

我在 Wikipedia 上读到了 Pragma 标头,它说:

“Pragma: no-cache 标头字段是用于请求的 HTTP/1.0 标头。它是浏览器告诉服务器和任何中间缓存它想要一个新版本的资源,而不是服务器的一种方式告诉浏览器不要缓存资源。一些用户代理在响应中确实注意这个标头,但是 HTTP/1.1 RFC 特别警告不要依赖这种行为。

但是一直没看懂是干什么的?值为 no-cacheCache-Control 标头与值为 no-cachePragma 之间有什么区别?


S
Shashank Agrawal

Pragma 是 HTTP/1.0 实现,cache-control 是同一概念的 HTTP/1.1 实现。它们都是为了防止客户端缓存响应。旧客户端可能不支持 HTTP/1.1,这就是该标头仍在使用的原因。


尽管下面cnst的答案要复杂得多,但根据规范,它也正确得多。 Pragma: no-cache 旨在仅在请求中使用(意思是“我想要原始文件,而不是缓存副本”),并且它的行为未指定用于响应。
Cache-Control: no-cache 对请求具有相同的含义,但实际上也是为响应定义的,意思是“如果您以后想使用它的缓存副本,您必须先与我确认它是最新的(即执行重新验证)”。
它用于缓存控制,它不必仅用于防止缓存,也可以用来表示“您可以缓存它”。 ……
基本答案。让它变得更复杂:它也是一个请求标头,这意味着您也可以向服务器发送 no-cache 。这实际上可能意味着将陈旧的内容返回给客户,什么?现在您忘记了这一点并阅读了上面的简单答案并享受生活,不要太努力地挖掘它哈哈
它们都是为了防止客户端缓存响应对于读者来说是一个令人困惑的注释。它也可以有 max-age,它不会阻止缓存。它只是为它设置了一个到期日期......
c
cnst

没有区别,除了 Pragma 只定义为适用于客户端的请求,而 Cache-Control 可以用于客户端的请求和服务器的回复。

因此,就标准而言,它们只能从客户端发出请求和服务器接收客户端请求的角度进行比较。 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.32 将场景定义如下:

HTTP/1.1 缓存应该将“Pragma: no-cache”视为客户端发送了“Cache-Control: no-cache”。 HTTP 中不会定义新的 Pragma 指令。注意:因为实际上没有指定“Pragma: no-cache as a response header field”的含义,所以它没有为响应中的“Cache-Control: no-cache”提供可靠的替换

我阅读上述内容的方式:

如果您正在编写客户端并且需要 no-cache:只需在请求中使用 Pragma: no-cache,因为您可能不知道服务器是否支持 Cache-Control;但在回复中,要决定是否缓存,请检查 Cache-Control

只需在请求中使用 Pragma: no-cache,因为您可能不知道服务器是否支持 Cache-Control;

但在回复中,要决定是否缓存,请检查 Cache-Control

如果您正在编写服务器:在解析来自客户端的请求时,检查 Cache-Control;如果没有找到,检查 Pragma: no-cache,并执行 Cache-Control: no-cache 逻辑;在回复中,提供 Cache-Control。

在解析来自客户端的请求时,检查 Cache-Control;如果没有找到,检查 Pragma: no-cache,并执行 Cache-Control: no-cache 逻辑;

在回复中,提供 Cache-Control。

当然,现实可能与 RFC 中所写或暗示的不同!


如果标题两者都有怎么办? Cache-Control: max-age=86400Pragma: no-cache?现代浏览器会尊重哪一个?
@PKHunter,如果行为未定义,您为什么要关心它的走向?如果您对服务器负责,显然您可以做得比向客户端提供误导性信息更好。此外,正如我在回答中指出的那样,Pragma: no-cache 仅针对来自浏览器的请求定义,因此在服务器对浏览器的回复中它完全无效且未定义,例如,我想每个浏览器 (无论是否现代)都应该在它可能收到的任何回复中忽略这样的标题。
如果两者都存在,现代浏览器应该忽略 Pragma 而支持 Cache-Control,因为后者可以指定时间段和其他在初始 1.0 协议中不可用的信息。
I
Ian Boyd

停止使用 (HTTP 1.0) 替换为 (HTTP 1.1 since 1999) Expires: [date] Cache-Control: max-age=[seconds] Pragma: no-cache Cache-Control: no-cache

如果是在 1999 年之后,而您仍在使用 Expires 或 Pragma,那么您做错了。

我在看着你 Stackoverflow:

200 OK Pragma: no-cache Content-Type: application/json X-Frame-Options: SAMEORIGIN X-Request-Guid: a3433194-4a03-4206-91ea-6a40f9bfd824 Strict-Transport-Security: max-age=15552000 Content-Length :54 接受范围:字节日期:2018 年 4 月 3 日星期二 19:03:12 GMT 通过:1.1 varnish 连接:keep-alive X-Served-By:cache-yyz8333-YYZ X-Cache:MISS X-Cache-Hits : 0 X-Timer: S1522782193.766958,VS0,VE30 Vary: Fastly-SSL X-DNS-Prefetch-Control: off Cache-Control: private

tl;dr:Pragma 是 HTTP/1.0 的遗留物,自 Internet Explorer 5 或 Netscape 4.7 以来就不再需要了。除非您希望您的某些用户使用 IE5:停止使用它是安全的。

过期:[日期](已弃用 - HTTP 1.0)

Pragma:无缓存(不推荐使用 - HTTP 1.0)

缓存控制:max-age=[秒]

Cache-Control:no-cache(每次都必须重新验证缓存的副本)

和有条件的要求:

基于 Etag(实体标签)的条件请求 服务器:Etag:W/“1d2e7–1648e509289” 客户端:If-None-Match:W/“1d2e7–1648e509289” 服务器:304 未修改

服务器:Etag:W/“1d2e7–1648e509289”

客户端:If-None-Match:W/“1d2e7–1648e509289”

服务器:304 未修改

基于修改日期的条件请求服务器:最后修改时间:2019 年 5 月 9 日星期四 19:15:47 GMT 客户端:If-Modified-Since:2018 年 7 月 13 日星期五 10:49:23 GMT 服务器:304 未修改

服务器:最后修改时间:2019 年 5 月 9 日星期四 19:15:47 GMT

客户:If-Modified-Since:2018 年 7 月 13 日星期五 10:49:23 GMT

服务器:304 未修改

最后修改时间:格林威治标准时间 2019 年 5 月 9 日星期四 19:15:47


RFC 说您应该同时使用它们,以防客户端不支持 Cache-Control:tools.ietf.org/html/rfc7234#page-29
client "ought to" 包括两者——除非它想区别对待 HTTP/1.1 和 HTTP/1.0 缓存服务器。服务器根本不应包含 Pragma(在 HTTP/1.0 中,Pragma 被定义为接收者的实现指定指令的可扩展字段。本规范弃用此类扩展以提高互操作性。)
从安全的角度来看,建议使用它。许多浏览器都遵循 pragma: no-cache 指令,因此 OWASP 建议使用它:owasp.org/index.php/…
@RandallBorck:您正在传播过时的(至少二十年!)信息。除非是 1999 年,否则任何浏览器都不再遵循 Pragma 指令了。这是货物崇拜的建议:“它没有坏处,我们一直都这样做,因此它是好的和必要的。”
@Piskvor 大多数服务器仍然支持 1.0 和 1.1,因此除非您主动阻止 HTTP/1.0 请求,否则您不会选择客户端使用的协议。今天的大多数开发人员都懒得阻止 1.0,因此它仍然是最佳实践,即使在 2019 年也是如此。