I found out that when pressing back button it gets previous page from browser cache even if I send following headers:
Test1.aspx
Server ASP.NET Development Server/9.0.0.0
Date Wed, 24 Mar 2010 17:49:40 GMT
X-AspNet-Version 2.0.50727
Location Test2.aspx
Cache-Control no-cache, no-store
Pragma no-cache
Expires -1
Content-Type text/html; charset=utf-8
Content-Length 189
Connection Close
expires should be a date+timestamp and cache-control"s "must-revalidata" & "max-age" might help as well?
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Cache-Control: no-cache, must-revalidate, max-age=0
Cache-control and such things only tell browser NOT to save in cache the downloaded stuff (js, css, images, etc.). It does not relate with the History of visited pages.
You shouldn't try to modify browser's data. Instead, you'd handle events and stop the ones you don't want to happen in your site.
For me the following setting in the header worked:
Pragma: no-cache
Cache-Control: no-cache, no-store
Expires: 0
Related
I'm experiencing an issue with Chrome that I can't seem to fully understand, I'm curious if folks here have dealt with it before. This doesn't reproduce in Firefox. The steps are as follows:
Start incognito Chrome, navigate to https://foo.mysite.com and have the JS on the page make a GET ajax request to S3 for https://s3.amazonaws.com/mystuff/file.json . You get back a 200 response with:
HTTP/1.1 200 OK
x-amz-id-2: somestuffhere
x-amz-request-id: somestuffhere
Date: Tue, 14 Oct 2014 03:06:41 GMT
Access-Control-Allow-Origin: https://foo.mysite.com
Access-Control-Allow-Methods: GET
Access-Control-Max-Age: 3000
Access-Control-Allow-Credentials: true
Vary: Origin, Access-Control-Request-Headers, Access-Control-Request-Method
Cache-Control: max-age=86400
Content-Encoding: gzip
Last-Modified: Sun, 05 Oct 2014 00:29:53 GMT
ETag: "fe76607baa40a793eb3b3cbd373a3fb8"
Accept-Ranges: bytes
Content-Type: application/json
Content-Length: 5609
Server: AmazonS3
Open a second tab, navigate to https://bar.mysite.com and have its JS make a GET ajax request to S3 for the same file https://s3.amazonaws.com/mystuff/file.json . Get back the following 304 response:
HTTP/1.1 304 Not Modified
x-amz-id-2: somestuffhere
x-amz-request-id: somestuffhere
Date: Tue, 14 Oct 2014 03:06:58 GMT
Access-Control-Allow-Origin: https://bar.mysite.com
Access-Control-Allow-Methods: GET
Access-Control-Max-Age: 3000
Access-Control-Allow-Credentials: true
Vary: Origin, Access-Control-Request-Headers, Access-Control-Request-Method
Cache-Control: max-age=86400
Last-Modified: Sun, 05 Oct 2014 00:29:53 GMT
ETag: "fe76607baa40a793eb3b3cbd373a3fb8"
Server: AmazonS3
Open a third tab, navigate to https://foo.mysite.com (the first site) and repeat the same steps as in 1. Chrome kills the response for CORS reasons and reports the following:
XMLHttpRequest cannot load https://s3.amazonaws.com/mystuff/file.json. The 'Access-Control-Allow-Origin' header has a value 'https://bar.mysite.com' that is not equal to the supplied origin. Origin 'https://foo.mysite.com' is therefore not allowed access.
What's the story here? This doesn't reproduce in Firefox. In Firefox I'm happily getting a 304 in both steps 2 and 3, which I would expect to see in Chrome as well.
A temporary workaround for this issue in Chrome is to set Cache-Control: no-cache on the file in S3, but then I'm forcing our clients to be re-downloading that file for no good reason, so it's not a real solution.
Is this intended and documented behavior? Is this a bug with Chrome? Any other thoughts?
Looks like this is caused by Chromium issue 260239
I found this blog that help: Add Vary headers to S3
It helped by adding Vary headers to all XHR request.
I did run into a problem with html request (i.e. ) but I was able to overcome that by using hackround#2 described here:https://serverfault.com/a/856948
TL;DR of hack#2 is to use a "dummy" query string parameter that differs for HTML and XHR or is absent from one or the other. Example:
<img src="https://s3.png?x-request=html">
I just add a timestamp in request URL to force load the asset from S3 again, not from cache, such as xxxx?timestamp=yyyy
This one works:
view-source:http://code.jquery.com/jquery-2.0.3.min.js
This one does not:
view-source:http://pagead2.googlesyndication.com/pagead/show_ads.js
The network status is "canceled". Response headers:
HTTP/1.1 200 OK
P3P: policyref="http://www.googleadservices.com/pagead/p3p.xml", CP="NOI DEV PSA PSD IVA IVD OTP OUR OTR IND OTC"
Content-Type: text/javascript; charset=UTF-8
ETag: 18135184975683587730
Date: Thu, 11 Jul 2013 10:00:44 GMT
Expires: Thu, 11 Jul 2013 11:00:44 GMT
X-Content-Type-Options: nosniff
Content-Disposition: attachment
Content-Encoding: gzip
Server: cafe
Content-Length: 6489
X-XSS-Protection: 1; mode=block
Age: 2014
Cache-Control: public, max-age=3600
Without "view-source" I'm able to download the file and view the source but I want to know why this happens.
A strange thing in addition is, that it is not possible to open the web delevoper tools after opening this view-source url. If you do, the tools are completely blank:
I'm taking a guess here: it has to do with the Content-Disposition setting in the Response Header.
Reference: http://support.microsoft.com/kb/260519.
I am playing around with HTML 5 cache manifests, and I am seeing a very strange issue in Chrome. Here's the page's header:
<html id="html" xmlns="http://www.w3.org/1999/xhtml" manifest="Portal/CacheManifestHandler.ashx">
Here are the manifest contents captured from fiddler:
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Type: text/cache-manifest; charset=utf-8
Expires: -1
Server: Microsoft-IIS/7.5
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Fri, 20 Apr 2012 15:56:20 GMT
Content-Length: 56
CACHE MANIFEST
NETWORK:
*
#Timestamp: 634705337615835020
I have one particular script on the page's header inside tag that is generated dynamically on server. Here are the contents returned for that script tag the first time user accesses the page:
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Type: text/javascript; charset=utf-8
Expires: -1
Server: Microsoft-IIS/7.5
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Fri, 20 Apr 2012 15:36:33 GMT
Content-Length: 74
document.location='/Portal/Login.aspx?ReturnUrl=%2fPortal%2fDefault.aspx';
You can see neither the script is in Cache-manifest, nor its headers allow browser (Chrome) to cache it.
Still when I subsequently open the same page in browser, Chrome loads the page from cache-manifest, which is okay.
However surprisingly it loads the <script> also from cache. I can verify it as my server breakpoints are not hit, nor does Fiddler show a request for this <script>. The network is not down and the server is accessible (this should not have made a difference because Chrome was asked to not cache this <script> anyways).
Is this the expected behavior? Shouldn't Chrome have requested the <script> again from server even when its containing page was loaded from manifest cache.
Chrome's chrome://appcache-internals also shows only 2 urls in the cache which again is fine, why then it loads the <script> from cache and not the server
We had the same issue, our resolution was to stick a * in the network section of our app.manifest so our Network section looked like
NETWORK:
*
I'm now digging to see if that's really "by design" for Google or just plain wrong.
I'm seeing the below response from some calls to a webserver:
Initial call:
HTTP/1.1 200 OK
Date: Mon, 16 Jan 2012 05:46:49 GMT
X-Powered-By: Servlet/2.5 JSP/2.1
Content-Type: text/plain
Content-Length: 78
Content-Encoding: gzip
Etag: "pv2052dae8634d971149a927231e3ceddf"
Cache-Control: no-cache
X-PvInfo: [S10202.C6191.A6057.RA6008.G182D.U3FAE8760].[OT/plaintext.OG/documents]
Vary: Accept-Encoding
Set-Cookie: JSESSIONID=l9pLPT5J1tpgK19Fq2qlT0F15ryByWDLgVLz16ffWPm4qQp6nzzx!-518520380; path=/; HttpOnly
DST=rd319o00000000000000000000ffffac16018bo8200; path=/
Connection: close
Subsequent calls:
HTTP/1.1 304 Not Modified
Date: Mon, 16 Jan 2012 05:48:43 GMT
Connection: close
Etag: "pv2052dae8634d971149a927231e3ceddf"
Cache-Control: no-cache
Vary: Accept-Encoding
What I'm unclear about is that both calls return a Cache-Control: no-cache directive to the browser.
However, the second call also returns a 304 Not Modified.
Where does the server expect the page to serve the data from, given that it's been instructed not to cache the earlier response?
Interestingly, I do see the response served in the browser, so the browser appears to have cached the response, despite the no-cache directive. Why?
A response with Cache-Control: no-cache does not mean that the response must not be stored at the client at all, instead it means:
If the no-cache directive does not specify a field-name, then a
cache MUST NOT use the response to satisfy a subsequent request
without successful revalidation with the origin server. This
allows an origin server to prevent caching even by caches that
have been configured to return stale responses to client requests.
So the client is allowed to store the response in the local cache but it needs to revalidate the response by the origin server. If the server says that the response stored in the client’s cache is still valid (i. e. 304 response), the client is allowed to use the stored response to satisfy the request.
I'm trying to do HEAD requests to follow 302 links, however this link: http://news.google.com/news/url?sa=t&fd=R&usg=AFQjCNGrJk-F7Dmshmtze2yhifxRsv8sRg&url=http://www.mtv.com/news/articles/1647243/20100907/story.jhtml
is troublesome because a HEAD request returns a 200 OK and a GET request returns the expected 302 Status code.
So I'll need to do a GET request but I'd rather not have to pay for the extra bandwidth times that will come from getting the entire HTML document. Anyone know a hack to do a GET without getting the body returned?
UPDATE: took David's advice to do a Range header but they seem to still be ignoring it
GET /news/url?sa=t&fd=R&usg=AFQjCNGrJk-F7Dmshmtze2yhifxRsv8sRg&url=http://www.mtv.com/news/articles/1647243/20100907/story.jhtml HTTP/1.1
Range: bytes=0-10
x-ms-range: 0-600
Host: news.google.com
Connection: Keep-Alive
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
HTTP/1.1 302 Moved Temporarily
Content-Type: text/html; charset=UTF-8
Location: http://www.mtv.com/news/articles/1647243/20100907/story.jhtml
Content-Length: 258
Date: Wed, 08 Sep 2010 20:28:16 GMT
Expires: Wed, 08 Sep 2010 20:28:16 GMT
Cache-Control: private, max-age=0
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Server: GSE
Set-Cookie: PREF=ID=ef5f1bc768645c5e:TM=1283977696:LM=1283977696:S=5n26IrEDpcQTJIb1; expires=Fri, 07-Sep-2012 20:28:16 GMT; path=/; domain=.google.com
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>302 Moved</TITLE></HEAD><BODY>
<H1>302 Moved</H1>
The document has moved
here.
</BODY></HTML>
File a bug with the web server's owner.
Try using the Range header in your request.
If that doesn't work, can you just hang up the connection after you get the headers you want?
In the specific example you cite, you could just pull it out of the original URL's "url" parameter. But for a more generic approach, I'd stick to David M.'s suggestions