Closed Bug 290193 Opened 20 years ago Closed 20 years ago

Page expired message is not showing all times even when HTTP header says no cache

Categories

(Core :: DOM: Navigation, defect)

Product:
Core
Component:
DOM: Navigation
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: jchittu, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2

If a page has no cache directive and expires header then browser should not
cache the page. If this page is resulted from a form post then when user hits
back button we should see a Warning message stating page is expired. This does
not happen at all in Firefox browser but in Mozilla 1.7.6 the behavior is
intermittent sometime the warning message but not all the time after a form
post. The attached JSP file in this bug demonstrated this behavior

Reproducible: Always

Steps to Reproduce:
Put this expirebug.jsp file in any http server.

<%@ page language="java" %>
<%
  //to expire page on the browser
  response.setHeader("Cache-Control", "no-cache"); // HTTP 1.1
  response.setHeader("Pragma", "no-cache"); // HTTP 1.0
  response.setDateHeader("Expires", -1); // Prevent caching at the proxy server
  if (request.getHeader("User-Agent").indexOf("MSIE") >= 0)
  {
    // HTTP 1.1.  Only way to force refresh in IE. For Others Bypass
    response.setStatus(HttpServletResponse.SC_RESET_CONTENT);
  }
  Integer pgCount = (Integer)pageContext.getAttribute("czPageSeq",
PageContext.SESSION_SCOPE);
  if (pgCount == null) {
    pgCount = new Integer(1);
  }
  else {
    int count = pgCount.intValue() + 1;
    pgCount = new Integer(count);
  }
  pageContext.setAttribute("czPageSeq", pgCount, PageContext.SESSION_SCOPE);
%>
<html>
<head>
<META HTTP-EQUIV="Expires" CONTENT="-1">
<META HTTP-EQUIV="Pragma" CONTENT="no-cache">
</head>
<body>
<h3>The page you are seeing should not be cached in browser.</h3>
<p>PageCount=<%= pageContext.getAttribute("czPageSeq",
PageContext.SESSION_SCOPE)%></p>

<form action="expirebug.jsp" method="post">
  <input type="hidden" name="n1" value="v1">
  <input type="submit" name"b1" value="Click here to post">
</form>
</body>
</html>

1. Launch the file from either Firefox or Mozilla or Netscape
2. Click the submit button couple of times you will see page counter increasing
3. Click on browser back button
4. Since the http header has content expiration set and each page is resulted
from a form post. We should see the warning message but it is not shown


Actual Results:  
No warning message is shown.

Expected Results:  
A warning message should have been displayed stating the page has expired do you
want to repost the form data?
> If a page has no cache directive and expires header then browser should not
> cache the page. If this page is resulted from a form post then when user hits
> back button we should see a Warning message stating page is expired.

Actually, no.  Please take a look at the http RFC for details.  If the page is
no-store or https and no-cache we'll do this, but otherwise history navigation
should be able to access the page.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
This error is reproducible. Did you try the attached JSP page. I will put this
in home my HTTP server for all of us to test it
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
My point was that the behavior you're seeing is correct.  no-cache doesn't mean
"user can't access through history".
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → INVALID
If user cannot access it throught history then browser should have shown a
Warning message but this doesn't happen for the attached test case. This is the
reason it is a bug
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
The point is, the user CAN access it through history.  Unless you're saying we
silently send a POST request to the server without prompting the user first?
Here is a test case showing the bug we are talking here.

1. Visit the site http://ckhima.dnsalias.com:8080/mozilla/expirebug.jsp
2. Click the button "Click here to Post" for a couple of times. Each time
browser makes a post request to a page and increments the counter.
3. The response page for each post action has a Expires header set and also
no-cache is also set. Browser should not be cacing this page at all.
4. Now click browser back button. Mozilla will simply redisplay the old cached
page. This is error. Instead it should show a warning message stating the page
has expired and needs to re-requested. 
> Browser should not be cacing this page at all.

OK.  Sure.

> This is error.

Wrong.  Please see
http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.13 which clearly says:

    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.  

So while no-cache does mean "don't show this again if an HTTP request is made",
a click on the back button actually doesn't make an HTTP request at all.

I said all this in comment 1 already; I'm not sure what made you decide that
doesn't apply to your case.

Again, this is invalid.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → INVALID
Please see
http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.13 which clearly says:

    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.


This depends on how one reads it. The spec clearly says History and cache
control are completely different. Yes i agree but the spec did not say what to
do when cache control is set to no-cache. The spec is open here and it depends
on how you view the problem.

If we say if cache control is set no-cache then browser should not be caching it
and when user access the page thru history mechanism if that page is not cached
then the browser should display a warning message stating the page is no longer
available. It should still keep the url in history but the content should not be
displayed and should let the user to either repost or let the user see just page
expired message. I feel this is the correct way to implement the spec rather
than simply redisplaying a expired page. If the browser simple redisplay a
expired page then there is no meaning for the no-cache header at all.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
> Yes i agree but the spec did not say what to do when cache control is set to
> no-cache.

Sure it does.  Section 14.9.1 clearly says that this header affects the behavior
of a _cache_.  See
<http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1>.  There is no
cache being used here.

> the page is no longer available.

The page is definitely available.  We have it.  It's just not in the HTTP cache,
per the no-cache header.  But we're not making an HTTP request.

> then there is no meaning for the no-cache header at all.

Sure there is.  It means to NOT CACHE.  So reloading, say, will always refetch
from the server (which it won't without no-cache), and clicking a link to the
page will always refetch from the server (again, it won't without no-cache).

Again, you seem to be looking for no-store, not no-cache.  That behaves exactly
the way you want, because we realize that sometimes people do want that behavior.

Please stop reopening this bug and wasting my time, ok?
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → INVALID
Component: History: Session → Document Navigation
QA Contact: history.session → docshell
You need to log in before you can comment on or make changes to this bug.