Closed Bug 99692 Opened 24 years ago Closed 24 years ago

Mozilla does not honor the "no-cache" pragma header

Categories

(Core :: Networking: HTTP, defect)

Product:
Core
Component:
Networking: HTTP
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED DUPLICATE of bug 104181

People

(Reporter: alan, Assigned: neeti)

Details

With the latest netscape 6.1 and mozilla nightly build (Mozilla 0.9.4+ Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4+) Gecko/20010914) I am finding that mozilla does not appear to honor the "no-cache" pragma tag when the "preferences->advanced->cache->compare page to cache" is set to "automatic". I would discount this as a setting issue except that using an "automatic" setting in IE 5.5 has the correct behaviour. The top of the html looks like: <html> <head> <meta HTTP-EQUIV="pragma" CONTENT="no-cache"> <title>Test</title> </head> <body BGCOLOR="white"> [...] The situation we have is we have a system where un-authenticated traffic on port 80 through the firewall is redirected to an alternate webserver, running on the firewall on a different port, which does authentication. The HTML for this page has the no-cache pragma on it. When the user is authenticated, the firewall is reconfigured to allow their ip out. When a mozilla user goes to the page they originally tried to go *by typing in the url in the URL bar and hitting enter* to they are sent to the alternate webserver again because the page is cached. Netscape 4.x (no automatic setting for cache) and ie 5.x (cache set to 'automatic') correctly get the "real" page from the network. Mozilla, Netscape 6.1 and IE 6.0 (with cache set to 'automatic') do NOT reload the page properly, and the user is sent to the same page again. Hitting shift-reload forces a reload and the correct page is then retrieved. To duplicate: - in your mozilla prefs set the cache setting to 'automatic' as above - set the firewall's webserver to have it's index.html with the meta tag of "pragma" "no-cache" as in the above html. - set up your gateway's firewall to redirect all outgoing port 80 traffic to port 8888: Assuming you have a linux gateway/firewall with ipchains and an internal ethernet of eth0: # ipchains -A input -i eth0 -p tcp --dport 80 -j REDIRECT 8888 - surf to mozilla.org - you will see the firewall webserver index.html page (as expected). - on your firewall, modify the firewall to remove the redirect: # ipchains -D input -i eth0 -p tcp --dport 80 -j REDIRECT 8888 - enter the same domain in the URL bar and hit enter - you will end up at the 8888 webserver again - hit shift-reload to force a reload - you'll now end up at the real website My appologies if the firewall set up is kinda hacky, but I hope I've gotten the gist of what is going on across :)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Darin, is "no-cache" the right tag here, or should they use "no-store"? Or is something else going wrong?
Assignee: gordon → neeti
Component: Networking: Cache → Networking: HTTP
cc'ing darin
<meta HTTP-EQUIV="pragma" CONTENT="no-cache"> should work... if not then this is a regression.
I can attest to the bug, too, even on https. What I have is a JSP page that users enter a form into. The form is posted to another JSP page which displays a wait page, something like "Processing Payment ... ", and this page in turn automatically posts ( via <body onLoad="document.waitform.submit();"> ) the form to the final intended servlet to do the actual processing. Once the processing is completed, a receipt is returned on a separate page. What SHOULD happen is that once the receipt page is displayed, if the user clicks on the "Back" button, it should do the same thing as Netscape 4.x or IE5 does ... that is, say that the page has expired from the cahce ( IE 5 ) or say "Data Missing" ( Netscape 4.x ). However, with 0.9.4 ( and even with 0.9.3 I believe ), hitting the Back button resends the form on the wait page, thereby sending a double payment. The wait page has the pragma no-cache and pragma expires=0 set. <meta http-equiv="Pragma" content="no-cache"> <meta http-equiv="Expires" content="0"> Heck, I even set the HTTP header for that page to: <% response.addHeader( "Pragma", "no-cache" ); %> <% response.addHeader( "Cache-Control", "no-cache"); %> <% response.addHeader( "Cache-Control", "no-store"); %> <% response.addHeader( "Cache-Control", "must-revalidate"); %> <% response.addHeader( "Cache-Control", "max-age=0"); %> <% response.addIntHeader( "Expires", 0 ); %> ... still, mozilla caches the wait page when it should not
OK, I understand the incessant confusion. The deal here is that the no-cache pragma header *is* affecting cache, and is obliterating information from cache, as expected. Reporter and Jesus Salvo, look at your server logs when you click "Back". You'll see a fresh request. BUT, Session History, a distinct entity from cache, still caches the form values. I'd like to see this fixed, and I'm CC'ing Radha Kulkarni. Session History/Forms stuff now falls into her lap. Darin's team did the right thing, but the buck stopped at going as far as Session History. Radha, correct me if I'm wrong. Radha, if this is yours, please change component.
radha: i'm thinking that we could add checks for additional headers when deciding whether or not to set the saveLayoutStateFlag... what do you think? i think necko should provide a method that does this, such as: nsIHttpChannel::IsNoCacheResponse() i'm also considering a method on nsICachingChannel.
Darin: I think that can and should be done. Are these methods in place? especially the nsIHTTPChannel call?
nope, the method doesn't exist. can you file a bug against me and mark it as blocking this one?
kay, I am a bit confused. Please note that I have not even peeked at the mozilla source, nor am I an expert in reading RFCs but... Arun, you said: "OK, I understand the incessant confusion. The deal here is that the no-cache pragma header *is* affecting cache, and is obliterating information from cache, as expected. Reporter and Jesus Salvo, look at your server logs when you click "Back"" Section 13.13 of RFC 2068 says that: "Rather, a history mechanism is meant to show __exactly__ what the user saw __at the time__ when the resource was retrieved." ( Emphasis mine ). If I understand this correctly, clicking on the "Back" button would try to retrieve the content from the user agent's cache. But since it is not in the cahce both due to meta no-cache and the HTTP header no-cache, the user agent should therefore NOT try to retrieve the content from the source, because doing so would mean that what the user saw earlier may / will not be the same as what the user will see again when the user clicks the "Back" button, violating Section 13.13 of the RFC. So my assumption here is that is why NS 4.x and IE would say "Data Missing" and "Page Expired" to the user, respectively. Am I correct in my interpretation?
Jesus, I'm surprised nightlies don't work for you, since you are sending a Cache-control: no-store header also. Try the latest Mozilla nightly. You ought to find that there's no double form submission, since you are sending Cache-Control: no-store. If there *still is* a double form submission, chip back in here -- that means that we did something wrong. But all my tests show that Cache-Control: no-store blows away Form values. This bug is logged to get Pragma to do the same thing that Cache-Control: no-store HTTP header does. Can you submit some HTML test cases so that I can create some test headers?
I never mentioned that I used the nightlies, only that we unit tested our webapp with mozilla 0.9.x ( 0.9.3 to 0.9.4 ).As mentioned here:http://www.freesoft.org/CIE/RFC/2068/154.htm"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."Again, my understanding of this is that clicking on the "Back" button would try to retrieve the content from the user agent's cache. But since it is not in the cache both due to meta no-cache and the HTTP header no-cache, the user agent should therefore NOT try to retrieve the content from the source, because doing so would mean that what the user saw earlier may / will not be the same as what the user will see again when the user clicks the "Back" button, violating Section 13.13 of the RFCContinuing with the RFC:"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."The emphasis there is: "__IF__ the entity is still in storage, a history mechanism should display it even if the entity has expired."Now with the scenario that I have, the entity is not in storage ( correct? ) since is had both META no-cache and HTTP header no-cache. The way I interpret this is the same like the previous paragraph, "Back" button should not retrieve the entity from the source since it is not in storage ( cache? )In any case, I may try out the nightlies and see if it solves anything.
jmsalvo: your reading of the RFC is correct; however, please note that it is merely a recommendation that useragents show what the user previously saw when pressing back. unfortunately, in order to maintain compatibility with existing web browsers, we must fix this bug.
marking as dupe of bug 104181, since that bug contains the patch to fix this. *** This bug has been marked as a duplicate of 104181 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
verified dup
Status: RESOLVED → VERIFIED
I know this has been marked as dup, but just to pitch in my latest test:Using mozilla 0.9.5 ( 2001101202 ), the behvaiour is now a little bit better. Here again is what was involved:Form page ----> wait page ---> Receipt pageUser enters payment info on form page, submits the form which displays the wait page. The wait page is the actual page that sends the payment to the payment gateway. It then displays the receipt page. In this scenario, wait page has no-cache in both HTTP header and META tags. It actually sends the payment info to the payment gw by posting the info to a specific URL via Javascript onLoad() on the BODY tag.In 0.9.4, when you click the Back button after getting the receipt page, you get double payments ... in that the view page is displayed again and a new receipt page ( with a new receipt number ) is shown.In 0.9.5, when you click the Back button after getting the receipt page, nothing really happens to the page shown ( although the moz [m] icon on the upper right was chanigng for awhile )). If I click on the Back button __again__, I get the Form page. At least in this case, double payment is avoided.So this is better than 0.9.4.
jesus: it's good to hear that mozilla is working better now.
You need to log in before you can comment on or make changes to this bug.