- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 26 Jun 2009 16:41:43 +1000
- To: Yngve N. Pettersen (Developer Opera Software ASA) <yngve@opera.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On 25/06/2009, at 8:06 PM, Yngve N. Pettersen (Developer Opera Software ASA) wrote: >> Yngve, why does must-revalidate affect user experience so much? All >> that it means is that you can't serve the response once it becomes >> stale. Does Opera ignore server-provided expiry as a matter of >> course? > > Opera treats the directive as a no-cache for history-navigation, and > that means that when you navigate back and forth in history all > resources in the document with that flag will be revalidated, before > they are displayed again. That causes a significant delay while > navigating. RFC2616 specifically states that the cache and history are separate (section 13.13). > It *may* be that we should also check expiration first (and that is > being considered, but may require significant changes), but the > purposes for which we added it, online banking, requires checking on > every view in any case. And as mentioned, the "primary" use of the > directive in many frameworks, such as PHP, combines must-revalidate > with no-cache and no-store. If you have users that need to restrict use of browser history (a well- worn topic), please come up with extension protocol directives, rather than abusing the existing ones. Section 13.13 talks about how improperly implemented history lists can persuade Web authors to not use must-revalidate, but as you've described your implementation, it's doing far worse -- it's eroding what trust authors have in the existing ones. Thanks, -- Mark Nottingham http://www.mnot.net/
Received on Friday, 26 June 2009 06:42:40 UTC