客户端导航控件是否应该重用旧响应或旧请求? [英] Should client navigation controls re-use old responses or old requests?
问题描述
来自 1999 年的 HTTP/1.1 RFC 2616,
来自 Firefox 开发者发布说明 '使用 Firefox 1.5 缓存':
<块引用>Firefox 1.5 对整个网页使用内存缓存,包括它们的 JavaScript 状态,用于单个浏览器会话.倒退并在访问的页面之间转发不需要页面加载,并且保留 JavaScript 状态.这个功能,被一些人称为bfcache(用于反向缓存"),使页面导航非常快.这种缓存状态会一直保留到用户关闭浏览器.
在某些情况下,Firefox 不缓存页面.以下是页面未缓存的一些常见编程原因:
- 页面使用了
unload
或beforeunload
处理程序; - 页面设置了缓存控制:无存储".
- 该站点是 HTTPS,并且页面集至少包含以下一项:
- 缓存控制:无缓存"
- Pragma:无缓存"
- 带有到期:0";或过期"具有相对于日期"的值的过去的日期值.标头(除非缓存控制:最大年龄="也指定);
- 当用户离开页面或由于其他原因(例如
XMLHttpRequest
));该页面正在运行 IndexedDB 事务; - 顶级页面包含由于此处列出的任何原因而无法缓存的框架(例如
);
- 页面在一个框架中,用户在该框架内加载一个新页面(在这种情况下,当用户离开页面时,最后加载到帧中的内容是缓存的内容).
如 RFC 7234 中所述并在 Firefox 1.5 发行说明中确认,客户端导航控件应重用旧响应而不是旧请求,除非明确告知不要在缓存指令中.
这或许可以解释有时返回时出现的表单重新提交的警告信息.
From 1999’s HTTP/1.1 RFC 2616, § 13.13. ‘History Lists’:
13.13 History Lists
User agents often have history mechanisms, such as "Back" buttons and history lists, which can be used to redisplay an entity retrieved earlier in a session.
History mechanisms and caches are different. In particular history mechanisms SHOULD NOT try to show a semantically transparent view of the current state of a resource. Rather, a history mechanism is meant to show exactly what the user saw at the time when the resource was retrieved.
By default, an expiration time does not apply to history mechanisms. If the entity is still in storage, a history mechanism SHOULD display it even if the entity has expired, unless the user has specifically configured the agent to refresh expired history documents.
This is not to be construed to prohibit the history mechanism from telling the user that a view might be stale.
Note: if history list mechanisms unnecessarily prevent users from viewing stale resources, this will tend to force service authors to avoid using HTTP expiration controls and cache controls when they would otherwise like to. Service authors may consider it important that users not be presented with error messages or warning messages when they use navigation controls (such as BACK) to view previously fetched resources. Even though sometimes such resources ought not to cached, or ought to expire quickly, user interface considerations may force service authors to resort to other means of preventing caching (e.g. "once-only" URLs) in order not to suffer the effects of improperly functioning history mechanisms.
From 2014’s HTTP/1.1 RFC 7234, § 6. ‘History Lists’:
6. History Lists
User agents often have history mechanisms, such as "Back" buttons and history lists, that can be used to redisplay a representation retrieved earlier in a session.
The freshness model (Section 4.2) does not necessarily apply to history mechanisms. That is, a history mechanism can display a previous representation even if it has expired.
This does not prohibit the history mechanism from telling the user that a view might be stale or from honoring cache directives (e.g., Cache-Control: no-store).
Does it mean that client navigation controls should re-use old responses instead of old requests? The former does not trigger a new network interaction with a new response from the server, while the latter does. This implies that the client’s history should store responses instead of requests.
And if that is so, why do Web browsers re-use old requests sometimes? For instance, going back after sending a POST request with form arguments may warn the user that the old request is about to be re-sent (form re-submission).
From Firefox developer release notes ‘Using Firefox 1.5 caching’:
Firefox 1.5 uses in-memory caching for entire Web pages, including their JavaScript states, for a single browser session. Going backward and forward between visited pages requires no page loading and the JavaScript states are preserved. This feature, referred to by some as bfcache (for "Back-Forward Cache"), makes page navigation very fast. This caching state is preserved until the user closes the browser.
There are instances in which Firefox doesn’t cache pages. Below are some common programmatic reasons that a page is not cached:
- the page uses an
unload
orbeforeunload
handler;- the page sets "cache-control: no-store".
- the site is HTTPS and page sets at least one of:
- "Cache-Control: no-cache"
- "Pragma: no-cache"
- with "Expires: 0" or "Expires" with a date value in the past relative to the value of the "Date" header (unless "Cache-Control: max-age=" is also specified);
- the page is not completely loaded when the user navigates away from it or has pending network requests for other reasons (e.g.
XMLHttpRequest
)); the page has running IndexedDB transactions;- the top-level page contains frames (e.g.
<iframe>
) that are not cacheable for any of the reasons listed here;- the page is in a frame and the user loads a new page within that frame (in this case, when the user navigates away from the page, the content that was last loaded into the frames is what is cached).
So as explained in RFC 7234 and confirmed in Firefox 1.5 release notes, client navigation controls should re-use old responses instead of old requests, unless explicitly told not to in cache directives.
This may explain the warning messages of form re-submission that appear when going back sometimes.
这篇关于客户端导航控件是否应该重用旧响应或旧请求?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!