Closed Bug 139541 Opened 22 years ago Closed 22 years ago

Pragma: no-cache pages not reloaded on back if memory cache > 0

Categories

(Core :: DOM: Navigation, defect)

Product:
Core
Component:
DOM: Navigation
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: sitsofe, Assigned: radha)

References

(
URL
)

Details

Steps to reproduce:
1. (Optionally set disk cache to 0) make sure you have set a value on memory cache
2. Set cache to always reload pages
3. Visit http://www.aber.ac.uk/cgi-bin/user/syswww/gw/mnemonic
4. Use a personal toolbar link to visit another page
5. Use the back button

Expected:
A different page to the one at step 3

Result:
Same page as at step 3

20020421 Linux
Just for the record (since we were talking about this on IRC), I feel that this
is the right behavior.  no-cache should not affect session history (as stated in
RFC 2616, section 13.13).
Oops I forgot to add that setting the memory cache to 0 makes this bug go away
within the comments.
Severity: normal → minor
Darin,  if I remember right, we load an updated page for 'Back' on a
pragma:no-cache page, only if it is a secure site. Am I right? can you comment
here.  Thanks. 
right, we only hit the net on back/forward if (no-store || (SSL && no-cache))
 we will not be supporting this behavior.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
Please, reopen this bug.

Why no-cache requires SSL to reload a page? MSIE reloads a page if no-cache is
set without SSL. Anyway, I have other fields like Expires set as well, but they
do not help, page is not reloaded:

Pragma: No-cache
Cache-Control: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT 

I also have these pragmas on the HTML page itself:

<meta HTTP-EQUIV="Pragma" content="no-cache">
<meta HTTP-EQUIV="Expires" content="-1">

This bug should be fixed, because it affects web sites which renew page content
each time a page is requested. Say, you submit a shopping basket, and then hit
Back. At this time the basket object is removed from the server, and server
sends an error page notifying a user that the basket does not exist anymore.
This does not work with Firefox, which shows the old basket content, which
causes the double submit.
> Why no-cache requires SSL to reload a page?

Did you read comment 1?  Essentially, Mozilla's behavior is exactly what is
required by the HTTP standard, with some concessions to the reality of secure
sites not wanting to be gone back to in many cases.

Your basket example should really be using SSL; I wouldn't trust any site with
an insecure basket...

If you really absolutely need things to not be cached on back, use no-store.
> Did you read comment 1?  Essentially, Mozilla's behavior is exactly what is
> required by the HTTP standard, with some concessions to the reality of secure
> sites not wanting to be gone back to in many cases.

Section 13.13 of RFC2116 uses words SHOULD and SHOULD NOT. According to RFC2119
"SHOULD, or the adjective "RECOMMENDED", mean that there may exist valid reasons
in particular circumstances to ignore a particular item, but the full
implications must be understood and carefully weighed before choosing a
different course."

Which means that RFC2616, section 13.13 does not prohibit from reloading a page.
What is more, it states: "This is not to be construed to prohibit the history
mechanism from telling the user that a view might be stale." Firefox does not
notify a user that a page is stale, nor it intervenes with resubmission of a
stale page.

MSIE does not cache pages marked as no-cache when going back. Well, I guess
Firefox is closer to the RFC2616, but there are some de-facto rules, and MSIE is
de-facto browser for Windows users. 

At the very least I would like to be notified (on the status bar maybe?) that
the page is stale. I would like to have a setting which would allow Firefox to
intervene when a stale page is submitted, and to notify a user about that fact.
I would like a default compatibility mode with MSIE on Windows, so a page WOULD
be reloaded by default.

> Your basket example should really be using SSL; I wouldn't trust any site with
> an insecure basket...

The basket was just an example of a form submission.

> If you really absolutely need things to not be cached on back, use no-store.

Thanks for no-store explanation, I will try to update my web-site with no-store
header, but I would have to do it manually. For example, Struts has an easy
setting in its config file:  <controller nocache="true"/>, which sets the
following fields only:

"Pragma: No-cache"
"Cache-Control: no-cache"
"Expires: Thu, 01 Jan 1970 00:00:00 GMT"

I guess I have to patch it. I can do it for my website, what about others, which
work fine on MSIE, but would fail on Firefox?
> At the very least I would like to be notified

Please file a separate bug on that.

You're correct that the RFC has a SHOULD.  That's why we have "carefully
weighed" the implications and not done the SHOULD part in cases where we feel it
would be wrong.  But for typical forms, it's not wrong, so....
From RFC 2616 section 13.13:

  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. 

Mozilla conforms to this recommendation.  It does not try to show a semantically
transparent view of the current state of the resource when the user navigates
back.  Instead, Mozilla attempts to show the resource as it was when the user
previously visited the resource.  "Cache-control: no-cache" is a cache
directive; it is not a history directive.  I fail to see where the RFC says that
Mozilla "SHOULD" treat "Cache-control: no-cache" as reason to expire content
from session history.

For practical reasons, we were forced to go against the recommendations of the
RFC in the case of HTTPS.  We did so because a number of online banks refused to
certify Mozilla otherwise.

I understand your concerns about the behavior of struts.  My suggestion to you
would be to file a bug against the struts package.  Perhaps it should provide
you with a convenient way of specifying "Cache-control: no-store" :-)
(In reply to comment #10)
> From RFC 2616 section 13.13:
<skipped>
> Mozilla conforms to this recommendation.  
> It does not try to show a semantically
> transparent view of the current state 
> of the resource when the user navigates
> back.  Instead, Mozilla attempts to show
> the resource as it was when the user
> previously visited the resource.  
> "Cache-control: no-cache" is a cache
> directive; it is not a history directive.

I understand that. Mozilla is going by the book in this case. But there is some
de-facto behavior common to most browsers which differ from HTTP specs. Like
redirect from POST to GET if received 302 response, while HTTP 1.1 clearly says
that method should (or does it say MUST?) be kept intact, that is, POST should
be redirected to POST. But everyone uses this functionality, so you implemented
it the same way as other browsers did.

> I fail to see where the RFC says that
> Mozilla "SHOULD" treat "Cache-control: no-cache"
> as reason to expire content from session history.

You are right, it does not.

> For practical reasons, we were forced to go against the recommendations of the
> RFC in the case of HTTPS.  We did so because a number of online banks refused
> to certify Mozilla otherwise.

You see, you already went against RFC, why would not you go a little further ;)
Banks require high level of security and run SSL over HTTP. But there are many
applications where one needs to submit a FORM using standard open connection,
and MSIE and older Netscape browsers (4.7 and 6.2 for example) reload a page
with no-cache header. While I understand your reasoning, you have to admit that
Firefox behaves differently, which may affect its acceptance by users of web
applications.

> I understand your concerns about the behavior of struts.  My suggestion to you
> would be to file a bug against the struts package.  Perhaps it should provide
> you with a convenient way of specifying "Cache-control: no-store" :-)

I will do that :) 

Anyway, I will file a separate change request about having a setting so Firefox
would either notify a user about submitting a stale FORM, or would behave like
MSIE which reloads no-cache page.

Thanks for quick responses and for pointing to no-store header.
> You see, you already went against RFC, why would not you go a little further ;)

That's a slippery slope! ;-)


> Banks require high level of security and run SSL over HTTP. But there are many
> applications where one needs to submit a FORM using standard open connection,
> and MSIE and older Netscape browsers (4.7 and 6.2 for example) reload a page
> with no-cache header. 

Yes, I hear your point.  You should know, that I once argued your point of view.
 See bug 112564 for all the gory details concerning the SSL-only implementation,
which went into affect Jan 2002.  That bug is full of arguments against the
change you desire.

As far as Netscape releases go, my patch first appeared in Netscape 7.0.  I
first attempted to implement the RFC in bug 101832.  That change did not make
the Netscape 6.2 release but went into the Mozilla trunk just after Netscape
branched for 6.2.


> While I understand your reasoning, you have to admit that
> Firefox behaves differently, which may affect its acceptance by users of web
> applications.

Firefox is consistent with Netscape 7.  This behavior has been around for nearly
2 and a half years (since Mozilla 0.9.8) without much in the way of complaints.
 The reason is that 'cache-control: no-store' exists as a way around the
problem.  Internet Explorer's behavior is based on the behavior of Netscape 4.x,
which was a HTTP/1.0 client.  HTTP/1.0 does not have the rich support for cache
control directives (like 'no-store'), so there was no way for 4.x to do any
better than simply not store 'no-cache' content.  If you ever used 4.x, you'd
know what a pain it was when you could not save a file or could not view its
source code because it had been deleted from the cache.  I believe that our
implementation is mostly good for users.  I understand the issue you
encountered, but fortunately it can be corrected on the server.


> Anyway, I will file a separate change request about having a setting so 
> Firefox would either notify a user about submitting a stale FORM or ...

Sounds like a good idea to me.
(In reply to comment #12)
> You should know, that I once argued your point of view.
>  See bug 112564 for all the gory details concerning the SSL-only implementation,
> which went into affect Jan 2002.  That bug is full of arguments against the
> change you desire.

I looked at the bug you referred to, and also to the bug 101832 and saw this: 
"mozilla acts like IE only when the server sends 'Cache-control: no-store'
because this directive tells mozilla to not put the page in the cache.  this has
the unforunate side effect of making view->source and file->saveAs require
server hits.  so, IMO encouraging web apps to send 'Cache-control: no-store' is
not a good idea."

So, view->source and file->saveAs require additional server hits. Not that I
really cared about ability of an end user to see the source of the page from my
site, but saveAs may be needed from time to time. Is it possible somehow to
achieve the following behavior:

* the page is reloaded if Back button is clicked (like currently in Mozilla with
"no-store" or in MSIE with "no-cache")
* view->source and file->saveAs do not require server hits (like currently with
"no-cache")
Just found bug 112564, comment 64: "2) put no-store content in cache to be
retrieved only for file->saveAs and view->source."

The issue is cleared, won't bother you guys anymore :)
Component: History: Session → Document Navigation
QA Contact: claudius → docshell
You need to log in before you can comment on or make changes to this bug.