I had this problem where CloudFlare wouldn't cache any of my pages because all of my pages returned session cookies. I've fixed this with a own written method, which removes unnecessary cookies from my response header. It's based on the same idea used and described here https://github.com/HaiFangHui/sessionmonster.
Currenlty i'm having this situation which is driving me bananas and i was hoping someone could help me out a little bit with your expertise about this subject.
I'm having this problem that after i login within my site after CloudFlare had it's chance to cache the page in a previous request... It will do that permanently untill the Edge TTL time expires.
Since the official CloudFlare documentation states it will not cache a page if it contains cookies i was hoping that after a succesfull login attempt it will serve a live/personalized version of the page. But so it seems that is not the case.
Does somebody know if this is normal? Of course i'm interested in knowing a way to circumvent this. I'm wondering how other sites solves this problem. My assumption would be i wouldn't be the first one having this issue.
Any advice regarding this subject would be greatly appreciated.
So it seems like supplying a "Bypass cache" setting is the solution.
It's only available on a paid plan.
More info: https://blog.cloudflare.com/caching-anonymous-page-views/
Related
We are hosting a major tennis tournament website and are trying to use Varnish on Rackspace to help with the traffic we anticipate. We have hired too systems consultants to help install Varnish on our cloud servers, but for whatever reason they are not able to get Varnish to work with our scripts. A typical script can be found here:
162.242.140.232/scoring/DemoGetOOP.php
There is nothing special about this script. It doesn't have any special caching commands in the headers and doesn't use session control. You can see by the date/time at the bottom that we have for testing purposes, that the page is not being cached. We set up a timer page which is cached:
162.242.140.232/scoring/timer.php
and also an info.php page at:
162.242.140.232/scoring/info.php
What's odd, is that if you first go to the timer.php, you can see it's cached for 10 seconds. However, if you then run our DemoGetOOP.php script and go back to timer.php, it's no longer cached. We have to clear the cache again or open up a private browser window to see the caching.
if (req.url ~ "^/scoring/DemoGetOOP.php") and
if (req.url ~ "/scoring/DemoGetOOP.php")
any help would be greatly appreciated!
S
First of all i would start with setting correct cache headers, i would prefer the Cache-Control header. The DemoGetOOP script also send a cookie, whereby Varnish will pass caching.
I would suggest to check the varnishlog which will give you a clear insight in why Varnish decides to cache or not.
They seem to be working fine to me, first link has a ttl of 120 seconds and the second link has a ttl of 10 seconds and both are working just fine.
I'd say always double check the cookies when things seem to be not workning.
This is a very strange one for me and I've been battling with it for a while now. I really hope someone can help.
I have a fairly typical MVC 3 Website and I only seem to be getting this problem in IE and Firefox. Chrome plays along nicely. Lucky for me, the majority of our company's clients uses Chrome at the moment.
Problem is at a seemingly random point in time, the browser will automatically redirect me to the Account/LogOff action when I click on a link, and from there it will obviously go back to the Login page. This link will then continue with the same behavior.
I say "seemingly random" because today that link will work, tomorrow it won't and all other (or the majority - I have never had more than on problem link giving this problem at a time) links will be fine. Sometimes restarting the server/dev environment will take care of the problem, other times it won't. The browser will just keep redirecting to LogOff.
I have tried looking at the Referrer URL, but the controller/action being referred to will never be reached. (If I place a breakpoint in the action, it is missed and the next point reached would be the LogOff action)
If I look at the stacktrace when in the LogOff Action, I can't see any info from where the application has come from. I have also tried what was suggested in this page: Posting the Stack Trace on ASP.NET MVC, but I cannot see why I am being redirected to the LogOff action.
The only place I seem to be able to have a breakpoint get hit before hitting LogOff, is Application_BeginRequest in the Global.asax, but can't see where it is going from there on.
My guess is that somewhere along the line, ASPNET Auth decides the user isn't authenticated any more and redirects to the LogOff action. Problem is that the cookies associated with ASPNET Auth all still exist, have data in them and they haven't expired yet.
Anyway, I hope I have given enough info on the problem.
Thanks in advance.
[Edit]
OK, so I might have gotten a step closer. I came across this link and looked to see what is happening in my Application_AuthenticateRequest in my global.asax.
I am not quite sure why, by when I click on a link, Application_AuthenticateRequest gets accessed 3 times. When a link works (as in I can follow it and it doesn't log me out), the value of the .ASPAUTH cookie stays the same. I checked this by adding a breakpoint and a watch over
HttpContext.Current.Request.Cookies[".ASPXAUTH"].Value
When the link does not work, the first time the cookie has a value, then the other two times it is null. Thus, because the ASPXAUTH cookie is null, the system automatically redirects to the LogOut action.
If I consider the solution they posted in the link, I am not sure if this applies to me. As far as I can tell, the encrypted cookie is still small (as in a few hundred characters long) and not close to 4096 bytes. Also, I have only 3 cookies going at the time I when tested the broken link and I have a maximum of 5 cookies at any given time.
Any idea?
OK, so I had a hunch about cookies expiring. So I looked at whether there is a way to keep (force) cookies in Forms Authentication alive and that led me to http://www.codeproject.com/Articles/221889/How-to-Generate-Machine-Key-in-IIS7
The only way I could test this theory was to keep working and debugging the site as normal. (And that's why it took me so long to post this answer.) Since I introduced this solution it seems that the problem has been solved.
Interestingly I spoke an Architect the other day, with 20 years dev experience, about my problem. He looked at my code and is convinced this is a bug in the Forms Authentication code.
I hope this helps some people who are experiencing the same problem I have.
I am using nanoc for one of my sites. I am wondering is there a way to do some good caching for the website. because everytime i update the page i need to hard refresh or refresh couple of times to have changes updated on the browser.
What should i do in order to have the page load the current content right after the first refresh ?
thanks
As I see it, this is not a nanoc question but more of a question related to the configuration of either your web server or your browser. Double-check your ETag, Last-Modified and Cache-Control headers. If I recall correctly, Firefox (still) caches aggressively, so that may explain your problem.
After running the YSlow plugin on a site, I saw that one of the recommendations was to add far future expires headers to the scripts, stylesheets, and images.
I asked a different question about how to set this up in IIS, but I am actually just curious about how each browser behaves.
I have read that IE will cache items per browsing session, so once you reopen the site after closing the browser, it will need to reload all of the content. I believe that Firefox will go ahead and set a expiration date on its own. I have also heard that IE does not cache at all when connecting over HTTPS. I am not sure if these are at all accurate, though, and was wondering if someone could clear up any misconceptions I may have. Thanks!
You are right about Firefox setting its own expiration date. See the second item in this blog post:
http://blog.httpwatch.com/2008/10/15/two-important-differences-between-firefox-and-ie-caching/
IE, like Firefox, can cache HTTPS based content. However, you need to set Cache-Control: public for persistent caching across browser sessions in Firefox. See Tip #3 in this blog post:
http://blog.httpwatch.com/2009/01/15/https-performance-tuning/
Is it possible to clear all site cache? I would like to do this when the user logs out or the session expires instead of instructing the browser not to cache on each request.
As far as I know, there is no way to instruct the browser to clear all the pages it has cached for your site. The only control that you, as a website author, have over caching of a page occurs when the browser tries to access that page. You can specify that cached versions of your pages should expire at a certain time using the Expires header, but even then the browser won't actually clear the page from its cache at that time.
i certainly hope not - that would give the web site destructive powers over the client machine!
If security is your main concern here, why not use HTTPS? Browsers don't cache content received via HTTPS (or cache it only in memory).
One tricky way to mimic this would be to include the session-id as a parameter when referencing any static piece of content on the site. When the user establishes the session, the browser will recognize all the pieces of content as new due to the inclusion of this parameter. For the duration of the session the browser will used the static content in its cache. After the user logs out and logs back in again, the session-id parameter for the static contents will be different, so the browser will recognize this is as completely new content and will download everything again.
That being said... this is a hack and I wouldn't recommend pursuing it.. For what reason do you want the user's cache to be cleared after their session expires? There's probably a better solution that can fit your situation as opposed to what you are currently asking for.
If you are talking about asp.net cache objects, you can use this:
For Each elem As DictionaryEntry In Cache
Cache.Remove(elem.Key)
Next
to remove items from the cache, but that may not be the full-extent of what you are trying to accomplish.