288462 - [Meta] Mozilla sometimes re-retrieves pages instead of re-using already-retrieved copy; violates RFC 2616 (Back, Send Page, etc.);

Reporter

Description

•

19 years ago

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217

In some cases, Mozilla retrieves a new version of a page instead of using the
previously-retrieved copy. (For example, Send Page doesn't send what you see;
it retrieves a new, possibly different, copy and sends that.)

This behavior violates both the spirit and letter of IETF RFC 2616, Hypertext
Transfer Protocol--HTTP/1.1. It also violates user expectations and fails to
meet user requirements.

Although this bug report partially duplicates several existing ones, I'm
hoping that this report can serve as a meta-bug report, so the issue
can be dealt with consistently by all the relevant commands and features in
Mozilla.

RFC 2616, section 13 (http://256.com/gray/docs/rfc2616/13.html#13.13)
says:

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.

Mozilla seems to violate the letter and the spirit of that specification in
several places, for example:
- When trying to go back to a page triggers the dialog box that says that
the page has expired and asking whether you want to re-post data,
Mozilla only gives you the options to re-post data or cancel; it does not
also give you the option to simply re-display the already-retrieved data.
- The Send Page command does not send what you see; it retrieves a new version
and sends that.
- If you get a page, get a second page, and then get the first page again,
then if you use Back, Back to try to get to the original version of the
first page, Mozilla displays the updated version instead of the original
version (what you saw two steps earlier).

Even ignoring what RFC 2616 says, Mozilla's behavior doesn't support user
needs and violates user expectations.

It seems that Mozilla has two, possibly systemic problems:
- Mozilla doesn't distinguish correctly between the page-data-history
mechansim (Back/Forward) and the HTTP caching mechanism.
- Commands that operate on the current page don't remember to operate on
the already-retrieved copy. Send Page definitely has this problem.
I thought I saw similar behavior with View Source, but I can't reproduce
it.

Reproducible: Always