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
Related
I found this article while searching if there is any VCL tweak that needs to be done while using varnish and cloudflare. I have currently not included the below tweaks suggested by cloudflare. Can anyone suggest if this is really needed?
Cloudflare varnish VCL configuration
Not a must do, but it may be a good idea to strip not-needed cookies, so that you can cache as much as you can.
Perhaps try with and without the snippet and check which behaviour works best for your use case.
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/
I was reading this guide of best practices by Yahoo:
http://developer.yahoo.com/performance/rules.html#no404
One rule that caught my eye is this.
HTTP requests are expensive so making an HTTP request and getting a
useless response (i.e. 404 Not Found) is totally unnecessary and will
slow down the user experience without any benefit.
Some sites have helpful 404s "Did you mean X?", which is great for the
user experience but also wastes server resources (like database, etc).
Particularly bad is when the link to an external JavaScript is wrong
and the result is a 404. First, this download will block parallel
downloads. Next the browser may try to parse the 404 response body as
if it were JavaScript code, trying to find something usable in it.
Is this really best practice?? If a user enters the wrong url on my website, what is this guide recommending? That I just leave the user with the default server error page? If the user enters the wrong url, how can the server return anything other than a 404? I simply don't understand this advice and wonder if anyone can explain the reasoning, thank you.
The best practice is that you serve different 404 documents in different situations.
For resources, that are not intended to be directly requested by a user but rather embedded into other documents (i.e., images, stylesheets, script files, etc.), should not result in a detailed error document but rather simply be empty, i.e., no body. With no body present, the browser won’t try to parse it.
But for resources, that are intended to be directly requested, a detailed 404 document with helpful information and guidance is better.
You could also take the presence of a Referer header field instead of the author’s intention as indicator whether a 404 document is useful or not.
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.
I'm trying to come up with ways to speed up my secure web site. Because there are a lot of CSS images that need to be loaded, it can slow down the site since secure resources are not cached to disk by the browser and must be retrieved more often than they really need to.
One thing I was considering is perhaps moving style-based images and javascript libraries to a non-secure sub-domain so that the browser could cache these resources that don't pose a security risk (a gradient isn't exactly sensitive material).
I wanted to see what other people thought about doing something like this. Is this a feasible idea or should I go about optimizing my site in other ways like using CSS sprite-maps, etc. to reduce requests and bandwidth?
Browsers (especially IE) get jumpy about this and alert users that there's mixed content on the page. We tried it and had a couple of users call in to question the security of our site. I wouldn't recommend it. Having users lose their sense of security when using your site is not worth the added speed.
Do not mix content, there is nothing more annoying then having to go and click the yes button on that dialog. I wish IE would let me always select show mixed content sites. As Chris said don't do it.
If you want to optimize your site, there are plenty of ways, if SSL is the only way left buy a hardware accelerator....hmmm if you load an image using http will it be cached if you load it with https? Just a side question that I need to go find out.
Be aware that in IE 7 there are issues with mixing secure and non-secure items on the same page, so this may result in some users not being able to view all the content of your pages properly. Not that I endorse IE 7, but recently I had to look into this issue, and it's a pain to deal with.
This is not advisable at all. The reason browsers give you such trouble about insecure content on secure pages is it exposes information about the current session and leaves you vulnerable to man-in-the-middle attacks. I'll grant there probably isn't much a 3rd party could do to sniff venerable info if the only insecured content is images, but CSS can contain reference to javascript/vbscript via behavior files (IE). If your javascript is served insecurely, there isn't much that can be done to prevent a rouge script scraping your webpage at an inopportune time.
At best, you might be able to get a way with iframing secure content to keep the look and feel. As a consumer I really don't like it, but as a web developer I've had to do that before due to no other pragmatic options. But, frankly, there's just as many if not more defects with that, too, as after all, you're hoping that something doesn't violate the integrity of the insecure content so that it may host the secure content and not some alternate content.
It's just not a great idea from a security perspective.