How do I configure my VLC to let Varnish respect the 'Cache-Control max-age' request header?
I noticed that by default varnish delivers cached content, even when I press F5 in my browser (Hence request a 'fresh' copy').
in vcl_hit you can do the following:
if (req.http.Cache-Control ~ '\no-cache\b`) {
purge;
return (restart);
}
make sure you have imported the std vmod
import std;
Related
I want to turn off caching for my HTTP responses. Here's my code:
public class CacheControlHeaderAttribute : ResponseFilterAttribute
{
public override void Execute(IRequest req, IResponse res, object responseDto)
{
res.AddHeader(HttpHeaders.CacheControl, "no-store,must-revalidate,no-cache,max-age=0");
res.AddHeader("X-Test", "Hello from ServiceStack!");
}
}
The problem is that it doesn't work. Cache-Control is getting set to private. How do I fix this?
You need to explicitly opt-in for HTTP Caching in ServiceStack which doesn't cache or add the HTTP Cache-Control header by default so I'm assuming it's being added by your Web Server which you'll want to look at configuring instead.
Otherwise adding HTTP Headers can be added using any of the options listed in Customize HTTP Responses.
But if it's not being returned something else fronting your App (e.g. Web Server / Proxy) is using their own Cache-Control headers.
I wish to deploy owncloud 9.x on two nodes behind a Varnish 3 server configured for round robin balancing.
By default my Varnish default.vcl cleans up all cookies except PHPSESSID.
I see that Owncloud session cookie name is not the usual PHPSESSID.
How can I change Varnish script accordingly?
or
How can I configure Owncloud to fallback to PHPSESSID?
Since my varnish serves multiple hosts the only solution I've found is
sub vcl_recv {
if( req.http.host ~ "owncloud" ) {
return(pass);
}
}
A weird CORS question...
I have code in my example.com server which returns the Access-Control-Allow-Origin response header for all POST & GET requests where the Origin request header is passed and it has a value of an example.com sub-domain (superman.example.com, batman.example.com, etc.).
I now need to be able to make AJAX calls passing cookies, so I need to be able to return the Access-Control-Allow-Credentials response header if the request includes cookies.
I could add an additional check to return the Access-Control-Allow-Credentials response header if I see the Cookie request header, but for simplicity, I'm wondering if there is any downside to always returning the Access-Control-Allow-Credentials response header for all GET/POST requests from my sub-domains, where the Origin request header is specified.
Here's my code (it's a Tcl iRule, FWIW):
when HTTP_REQUEST priority 200 {
if { ( [HTTP::method] equals "OPTIONS" ) and
( [HTTP::host] ends_with "example.com"] ) and
( [HTTP::header exists "Access-Control-Request-Method"]) } {
HTTP::respond 200 "Access-Control-Allow-Origin" [HTTP::header "Origin"] \
"Access-Control-Allow-Methods" "POST, GET, OPTIONS" \
"Access-Control-Allow-Headers" [HTTP::header "Access-Control-Request-Headers"] \
"Access-Control-Max-Age" "86400"
} elseif { ( [HTTP::host] ends_with "example.com"] ) and
( [HTTP::header exists "Origin"]) } {
# CORS GET/POST requests - set cors_origin variable
set cors_origin [HTTP::header "Origin"]
}
}
when HTTP_RESPONSE {
# CORS GET/POST response - check cors_origin variable set in request
if { [info exists cors_origin] } {
HTTP::header insert "Access-Control-Allow-Origin" $cors_origin
HTTP::header insert "Access-Control-Allow-Credentials" "true"
}
}
I am aware that if I return the Access-Control-Allow-Credentials response header, I have to specify a named (non-generic) Access-Control-Allow-Origin header (and that may have Vary header issues), but is there anything else I need to be aware of?
If you take defence in depth into consideration, unconditionally including
Access-Control-Allow-Credentials: true
in responses is a bad idea. Your app may indeed be vulnerable to HTTP-header injection. Imagine a situation where the attacker is able to inject—perhaps via a query parameter in the URL—exactly one arbitrary HTTP header in the response. In that case, the attacker would effectively be able to force responses to contain the following headers,
Access-Control-Allow-Origin: https://attacker.com
Access-Control-Allow-Credentials: true
which would leave the content wide open to cross-origin attacks from https://attacker.com.
James Kettle mentions something similar in his AppSecUSA 2016 talk, entitled Exploiting CORS Misconfigurations for Bitcoins and Bounties:
It's quite common to find classic HTTP-header-injection vulnerabilities where, for whatever reason, you can't inject into the response content. You can't just inject malicious HTML; the only thing you can do is set HTTP
headers. And CORS offers a brilliant way of exploiting this because you can just say
This content is open to everyone!
using CORS and then attackers can get hold of that [...]
I'd like to know what can I put in my VCL to tell Varnish to not cache the requests and pass all the requests to the backend, because I would like to use Varnish as a reverse proxy to hide the actual IP of my backends.
I did some researches but I didn't find anything concrete.
I'm using Varnish 3 and my actual Varnish VCl is:
backend default {
.host = "127.0.0.1";
.port = "8080";
}
Thank you.
if you want varnish to do nothing with the request at all you should use pipe. This prevents varnish from rewriting the headers. The response is sent back from varnish directly.
sub vcl_recv {
return(pipe);
}
You'll need to overwrite the default handling to force a 'pass'
This in both vcl_recv and vcl_fetch
sub vcl_recv {
pass; }
sub vcl_fetch {
pass; }
I need to do custom Varnish VCL configuration for cookie based by-pass objects.
So, Varnish keep serving my cached pages unless user logged in.
How can i prevent access to non-logged users? for specific pages or regex etc.
Using:
Varnish 3 on Nginx, Ubuntu 64. bit EC2 instance
That's the varnish default behaviour, excerpt from the default config [1]:
sub vcl_recv {
#...
if (req.http.Authorization || req.http.Cookie) {
/* Not cacheable by default */
return (pass);
}
#...
}
[1] https://www.varnish-cache.org/docs/3.0/reference/vcl.html#examples