I am using CouchDB for a web app and having problems with IE8 caching the results of a view. From my reading it seems one solution would be to change the "Cache-Control" HTTP header to "no-cache". Right now the CouchDB returns the value "must-revalidate".
Is there a way to change the value of this header at all? Can it just be changed for the view?
FYI if you are using jQuery just remember to include cache:false as one of your options in your $.ajax() calls.
CouchDB should be using Etags that change whenever the view content or code changes. However, looking through CouchDB's bug database it looks like there is a cache issue with Internet Explorer that's been unsolved for a while. If that looks like the problem you're having, it might be helpful to propose a fix in the bug ticket or at least remind the CouchDB mailinglist/IRC of the issue.
It looks like the issue is simply IE's bug though, so some sort of workaround might be necessary, like querying the view with the age old extra random parameter hack to make the URL unique when you know you would otherwise encounter a cache issue.
Related
I'm new to varnish and I'm setting up for some of the websites I manage.
One of the difficulties I'm having is to debug it. I know that there's varnishlog, but it would be really helpful to have something similar to W3C logging for all request served by varnish. In addition to standard fields, there will be one extra field to show if the request was served from cache, from back-end, etc.
Is there something like this or a way to have this kind of log?
Thanx,
Albert
For anyone looking for this, the solution is varnishncsa
Edit : I don't know if it actually loads from cache, so I can't create the question named "prevent from loading cache".
Problem : Browsers sometimes save my code and keep loading only the code they saved(Maybe it saves in the cache). When this problem occurs, browser is like caching the old code and won't change anything. This is to say, It won't load any new code I updated.
Information: This occurs in HTML, CSS, Javascript on all browsers. I am using Apache in XAMPP as an appserv.
Deleting cache in all browsers won't fix this.
My first way to stop this is to delete the file, refresh browser and replace it.
The second ways is changing the pathname.
After the fix, the problem will occur again at anytime :(, so I would like to know how to prevent this.
Edited: If possible, please explain for newbie because I am very young beginner.
Try adding a variable like current timestamp to each url in its query string.
Just use querystring e.g. http://www.domain.com/style.css?version=1 for first version.
Now you update the stylesheet and you would like to reflact changes to all users browser who have cached version of old stylesheet. for this just change version querystring value to 1.1
e.g. http://www.domain.com/style.css?version=1.1
This works for javascript, css and all other files called in by your html page.
Also for all files like html, css, js, you can eTag header. More information can be found here.
http://www.w3.org/2005/MWI/BPWG/techs/CachingWithETag.html
I've got a bug report from the field that essentially boils down to image caching. Namely, an image from the same URL is getting cached and it's causing confusion because the image itself is supposed to change.
My fix is to do this bit here. Which I'm certain will work.
However - I can't freaking reproduce this. I would prefer not to do the methods I've seen here because they require code modification and I'd rather test this on the code as it exists now before I test a fix.
Is there any way in a browser like IE to force it to cache like mad? Just temporarily, of course.
You can use Fiddler to force things to cache or not to cache; just use the Filters tab and add a caching header like
Cache-Control: public,max-age=3600
You can have the customer use www.fiddlercap.com to collect a traffic capture so you can see exactly what they see.
You should also understand that the proper way to control caching is by setting HTTP headers rather than forcing the browser to guess: http://blogs.msdn.com/b/ie/archive/2010/07/14/caching-improvements-in-internet-explorer-9.aspx
I'm having a strange issue in the ACP where the manage categories page looks like this: http://screencast.com/t/IcNbpP87 I'd really appreciate any insight you guys may be able to provide.
I've looked around for a couple days and am pulling my hair out.
Chrome
Displays a “New Root Category” form but you are unable to click a category to modify it.
Firefox & Safari:
Seems to return the proper data via ajax from the server, though it displays the information without parsing(?)
Looking at the source in firebug, it looks like data that isn’t being parsed correctly within the otherwise correct <div id="category-edit-container" class="category-content">
Source reference: http://pastebin.com/Zz7pKajj
I’d appreciate any suggestion on how to potentially move forward and get this fixed up. Thanks!
After going two day crazy with this issue in our case the solution was on the most unexpected location: It was the index.php that was corrupted the culprit. After removing some spurious code that seemed that was injected or by some way modified all is working as expected.
If there is content before the doctype header you will get this error. Check for that.
Here's the situation:
I have a web application which response to a request for a list of resources, lets say:
/items
This is initially requested directly by the web browser by navigating to that path. The browser uses it's standard "Accept" header which includes "text/html" and my application notices this and returns the HTML content for the item list.
Within the returned HTML is some JavaScript (jQuery), which then does an ajax request to retrieve the actual data:
/items
Only this time, the "Accept" header is explicitly set to "application/json". Again, my application notices this and JSON is correctly returned to the request, the data is inserted into the page, and everything is happy.
Here comes the problem: The user navigates to another page, and later presses the BACK button. They are then prompted to save a file. This turns out to be the JSON data of the item list.
So far I've confirmed this to happen in both Google Chrome and Firefox 3.5.
There's two possible types of answers here:
How can I fix the problem. Is
there some magic combination of
Cache-Control headers, or other
voodoo which cause the browser to do
the right thing here?
If you think I am doing something
horribly wrong here, how should I go
about this? I'm seeking correctness,
but also trying not to sacrifice
flexibility.
If it helps, the application is a JAX-RS web application, using Restlet 2.0m4. I can provide sample request/response headers if it's helpful but I believe the issue is completely reproducible.
Is there some magic combination of Cache-Control headers, or other voodoo which cause the browser to do the right thing here?
If you serve different responses to different Accept: headers, you must include the header:
Vary: Accept
in your response. The Vary header should also contain any other request headers that influence the response, so for example if you do gzip/deflate compression you'd have to include Accept-Encoding.
IE, unfortunately handles many values of Vary poorly, breaking cacheing completely, which might or might not matter to you.
If you think I am doing something horribly wrong here, how should I go about this?
I don't think the idea of serving different content for different types at the same URL is horribly wrong, but you are letting yourself in for more compatibility problems than you really need. Relying on headers working through JSON isn't really a great idea in practice; you'd be best off just having a different URL, such as /items/json or /items?format=json.
I know this question is old, but just in case anyone else runs into this:
I was having this same problem with a Rails application using jQuery, and I fixed it by telling the browser not to cache the JSON response with the solution given here to a different question:
jQuery $.getJSON works only once for each control. Doesn't reach the server again
The problem only seemed to occur with Chrome and Firefox. Safari was handling the back behavior okay without explicitly having to tell it to not cache.
Old question, but for anyone else seeing this, there is nothing wrong with the questioner's usage of the Accept header.
This is a confirmed bug in Chrome. (Previously also in Firefox but since fixed.)
http://code.google.com/p/chromium/issues/detail?id=94369