I use ajax request beside pushing history state to load new content and update the entire page. At the server the X-Requested-With header is used to decide to send the full page or just the content. But it seems chrome tends to use the cache no matter it's loaded with ajax or normal request (it doesn't respect headers when checking the cache).
The problem happens when I open a site page, I click a link to navigate to a new page using ajax then navigate to a new page by entering the url in address bar. When I hit back the ajax cached version (no matter it's html or json) is shown instead of full page. When the cache is disabled everything works fine.
Is there any way to force chrome respect the request headers when checking the cache?
After some research I found out that browsers tend to cache responses base on Request Method as well as URL. So they won't consider any request headers when checking the cache by default. But it's possible to force the browser to respect some headers when checking the cache by using Vary header.
So by adding this header (Vary:X-Requested-With) to each response that changes based on X-Requested-With request header, server is telling browser that this response may vary if your X-Requested-With header is changed and you must request a new response.
Related
My goal is to cache images in browser's cache.
Current setup
Cache-Control: public, max-age=10368000 header is attached to the requested image to cache the image.
Furthermore, ETag: f5f9f1fb39790a06c5b93735ac6e2397 header is attached too to check if image has changed once max-age is reached.
When the same image is requested again, if-none-match header's value is checked to see if image has changed. If it has not, 304 is returned.
I am using Fiddler to inspect http traffic (note - behaviour described below was happening already before Fiddler, so it is not the problem)
Chrome version - 77.0.3865.90 (Official Build) (64-bit)
Expected behaviour
I expect that the image would get cached 10368000 seconds. Unless 10368000 seconds have passed, image gets served from browser's cache on each request. Once 10368000 seconds have passed, request is made to the server which checks Etag. If the image has not changed on the server, return 304 to the client and extend caching period to another 10368000 seconds.
Behaviour with Google Chrome
Image gets requested for the first time. Below are the request headers
Image is returned successfully with 200 status. Below are the response headers
Fiddler tells that an image was requested and served
Furthermore, the fact that the image is cached is seen in ~/Library/Caches/Google/Chrome as it appears there.
I click on the link bar in browser and press Enter to request the image again. Below are the request headers
Image is returned successfully with 304 status. Below are the response headers
Fiddler tells that image was served from the cache
Why did Chrome make an additional request for the image and served it from the cache only after it received 304 response?
I see that when requesting the image second time Cache-Control: max-age=0 request header is set. As I understand, it means that Chrome wants to re-validate if cached image is valid before serving it. But why?
Some people online have told that Etag header is the reason for Chrome making sure images are valid. Even if I do not include Etag header, just have Cache-Control: public, max-age=10368000 in the first response, the Cache-Control: max-age=0 exists in second request's headers.
I have also tried excluding public, making it private etc. I also added Expires and Last-Modified pair with and without max-age=10368000 and get the same behaviour.
Furthermore, in dev tools I have NOT checked Disable cache. So the cache is enabled for sure which also makes sense because the image was served after returning 304.
This exact behaviour happens also when, instead of clicking link bar and pressing Enter, I press Refresh arrow aka CMD + R. If I do hard refresh CMD + SHIFT + R, then the image is requested as if it is first time requesting it, which makes sense.
Behaviour with Firefox
Firefox works exactly as expected.
Image gets requested for the first time. Below are the request headers
Image is returned successfully with 200 status. Below are the response headers
Fiddler tells that an image was requested and served
Furthermore, if I hover over response status, then it says OK
I click on the link bar in browser and press Enter to request the image again. Below are the request headers
Image is returned successfully with 200 status. Below are the response headers
BUT Firefox shows that it was cached.
FURTHERMORE, Fiddler detected no activity on the second request, so the image was served from Firefox's cache. Unlike Chrome, which made another request to the server just to receive 304 from it.
Thank you very much for your time and help. I highly appreciate it and am open to provide any other information. Really looking forward to what you think about this.
Have a nice day :)
Why did Chrome make an additional request for the image and served it from the cache only after it received 304 response?
Because you told it to - whether you realise it or not! When you browse forwards and backwards the cached image will be used. When you click refresh or F5 (Cmd R on MacOS) or a page, you are explicitly asking Chrome to double check if the page is still the correct one. So when you click on the URL bar and click enter it’s the same thing. Chrome thinks that the only reason you’d do that, on a URL you are already on, you must want it to check.
I see that when requesting the image second time Cache-Control: max-age=0 request header is set. As I understand, it means that Chrome wants to re-validate if cached image is valid before serving it. But why?
Correct. See the answer to this question. As to why - because as per above you have Chrome a signal you wanted to refresh.
There is also the cache-control immutable header, which is designed to tell the browser never to re-fetch if in the cache - even on refresh.
Firefox works exactly as expected.
Interesting. I actually like the way Chrome does this. Certainly for reload (F5/Cmd + R). Appreciate it confused you (though hopefully will be less confusing now you understand it), but testing this is not the norm, and most people don’t click the URL bar and then hit enter without changing the URL unless they want to recheck the current page with the server.
I have set content caching on a specific folder by following the local web.config method. I don't think it works, and I would like to fix this.
I activate the cache using the IIS / HTTP Headers / Common headers feature. I set them to 1 day of expiration.
I opened a page with Google Chrome in private navigation, and then open the Network tab in the console.
The first time I load the page, everything loads from the site, obviously.
If I refresh the page, I see 2 types of loading in the Network console:
the files from Google and Facebook and such have a status of 200, and a size of (from cache).
the files from the folder for which I set the caching have a status of 304 and their size is displayed.
So, I guess the caching setting doesn't work? Or does the 304 response means that it's loaded from the cache? If they aren't, how can I make it work ?
Thanks !
304 is a way of caching. The server says that the content of the resource hasn't changed and it doesn't have to send the response content (the response content is empty).
This is quite convenient. The browser still makes the request for the resource (so that when it changes the new content is delivered to the client) but the server possibly saves the bandwidth by sending 304 + empty body instead of 200 and body content.
Is it possible to change the HTTP_REFERER value in VBScript? To avoid XSS attacks I am using CSRF data in my links. But when I am linking the user to an external website, this CSRF data could be caught by the destination webpage if they are checking the HTTP_REFERER.
So I read you should put an intermediate page in between, which will redirect to the desired page. So I tried creating a page named RedirectPage.asp which takes the URL as a parameter and does a Server.Redirect. But if I would click an external link on pagex.asp?CSRF..., the final HTTP_REFERER I catch is still pagex.asp.
So is there a way to "clean up" my REFERER header?
Thanks!!
By using a meta redirect instead of a redirect header, you can alter the referrer in Firefox and IE, but not Chrome, as mentioned here: https://stackoverflow.com/a/2985629/160565
You can consistently clear (not change, but eliminate) the http_referer by redirecting through an SSL page however.
To save yourself a redirect, you could also check for browsers that support the rel="noreferrer" html5 attribute and use that instead in those cases. I believe currently that's just webkit browsers.
http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#link-type-noreferrer
It's well known that Internet Explorer aggressively caches ajax calls whereas all the other browsers grab the data fresh every time. This is usually bad: I've never encountered a case where I want ajax to NOT contact the server. Firefox, Safari and the other browsers know this and don't cache ajax calls.
To prevent IE from caching, you have to do one of the following:
add a cache-busting token to the query string (like ?time=[timestamp])
send a HTTP response header that specifically forbids IE to cache the request
use an ajax POST instead of a GET
I much prefer setting a no-cache header. It's the correct way: it tells all browsers not to cache, which is exactly what you intend. The query string method fills up the browser's cache with stuff that'll never be retrieved, leaving less room for legitimate cache content. And the POST method is a corruption of HTTP: POSTs are for modifying data.
In Grails, what's the best way to automatically send a do-not-cache header for all ajax requests? I don't want to modify any controllers, so I'm thinking there's got to be a cool filter trick or something.
Thanks!
Here's what I finally figured out. Most javascript libraries --including jQuery, YUI, Mootools and Prototype -- send the X-Requested-With: XmlHttpRequest header on every ajax request.
For any request that sends this header, you can send a response header back that tells it to not cache.
Below is a Grails filter that prevents caching of ajax requests that identify themselves with the X-Requested-With: XmlHttpRequest header:
// put this class in grails-app/config/
class AjaxFilters {
def filters = {
all(controller:'*', action:'*') {
before = {
if (request.getHeader('X-Requested-With')?.equals('XMLHttpRequest')) {
response.setHeader('Expires', '-1')
}
}
}
}
}
Some people prefer to use the Cache-Control: no-cache header instead of expires. Here's the difference:
Cache-Control: no-cache - absolutely NO caching
Expires: -1 - the browser "usually" contacts the Web server for updates to that page via a conditional If-Modified-Since request. However, the page remains in the disk cache and is used in appropriate situations without contacting the remote Web server, such as when the BACK and FORWARD buttons are used to access the navigation history or when the browser is in offline mode.
By adding this filter, you make Internet Explorer's caching consistent with what Firefox and Safari already do.
BTW, I've experienced the caching problem on IE8 and IE9. I assume the problem existed for IE7 and IE6 as well.
We use jQuery for all ajax calls so we add this block to our main.gsp (top-level layout):
<g:javascript>
jQuery(document).ready(function() {
$.ajaxSetup({
cache:false
});
});
</g:javascript>
Also answered here
Can I call the server to set a new cookie with an AJAX request (that is, after the page has already loaded)?
For example, when a visitor hits a link, ajax would open a php file that sets a new cookie like this:
setcookie('cookiename', 'true', time()+3000, "/",'...');
But this is done after the html (the page containing the actual <a> tag pressed) was rendered. Is it nevertheless ok to set cookies in ajax? (maybe because the php file loaded is separate from the original html page).
You can have the server's response set a cookie, certainly. Remember that cookies are an HTTP thing, not an HTML thing; the fact that your original HTML file is already on the browser is irrelevant. Your ajax request is a separate HTTP request to the server, which (hopefully!) generates an HTTP response back to the browser; and that response can include a new Set-Cookie header.
I'm not a PHP person, you'll need to check that there are limitations in the PHP mechanism you're using for setting the cookie (I can't imagine there are). But fundamentally, no, there's no problem doing this. I've done it with both JSPs and classic ASP.
I've set cookies in the response to AJAX requests on my site and I haven't had any problems with it yet. (Although I haven't looked for problems.) It could be that some browsers don't set cookies when receiving them in an XmlHttpRequest but so far I've seen it work in IE, Chrome and Firefox.
Why not use javascript to edit cookies? Return the content of the cookie in JSON format and use javascript to store the values.