Mar*_*itt 6 html http http-headers
我从网络服务器的一些调用中看到以下响应:
初次通话:
HTTP/1.1 200 OK
Date: Mon, 16 Jan 2012 05:46:49 GMT
X-Powered-By: Servlet/2.5 JSP/2.1
Content-Type: text/plain
Content-Length: 78
Content-Encoding: gzip
Etag: "pv2052dae8634d971149a927231e3ceddf"
Cache-Control: no-cache
X-PvInfo: [S10202.C6191.A6057.RA6008.G182D.U3FAE8760].[OT/plaintext.OG/documents]
Vary: Accept-Encoding
Set-Cookie: JSESSIONID=l9pLPT5J1tpgK19Fq2qlT0F15ryByWDLgVLz16ffWPm4qQp6nzzx!-518520380; path=/; HttpOnly
DST=rd319o00000000000000000000ffffac16018bo8200; path=/
Connection: close
Run Code Online (Sandbox Code Playgroud)
后续电话:
HTTP/1.1 304 Not Modified
Date: Mon, 16 Jan 2012 05:48:43 GMT
Connection: close
Etag: "pv2052dae8634d971149a927231e3ceddf"
Cache-Control: no-cache
Vary: Accept-Encoding
Run Code Online (Sandbox Code Playgroud)
我不清楚的是两个调用都会Cache-Control: no-cache向浏览器返回一个指令.
但是,第二次调用也会返回一个304 Not Modified.
服务器在哪里期望页面提供数据,因为它已被指示不缓存早期的响应?
有趣的是,我确实看到在浏览器中提供了响应,因此尽管使用了no-cache指令,浏览器似乎已缓存了响应.为什么?
Gum*_*mbo 19
一个有响应Cache-Control: no-cache并不意味着响应不得存储在客户端可言,相反,它的意思是:
如果no-cache指令没有指定字段名,那么缓存绝不能使用响应来满足后续请求,而不能成功地与源服务器重新验证.这允许源服务器甚至通过已配置为返回对客户端请求的陈旧响应的缓存来防止缓存.
因此,允许客户端将响应存储在本地缓存中,但它需要重新验证源服务器的响应.如果服务器说存储在客户端缓存中的响应仍然有效(即304响应),则允许客户端使用存储的响应来满足请求.