Fastly’s request condition is applied to the latest matching condition
If you want Fastly to switch origin (backend) according to a condition, you can do so by setting a request condition. I misunderstood the behavior of the request condition and got into trouble, so I’ll show you what I misunderstood and how I dealt with it.
Request condition⌗
The Request condition has a priority, and the default is 10. The lower the value, it will be evaluated first, and all request conditions will be evaluated. The following is an example of a request condition.
- Request condition 1
- priority: 10
- condition:
req.http.host == "foo.example.com" && req.url.path ~ "^/v2"
- backend:
bar.example.com
- Request condition 2
- priority: 20
- condition:
req.http.host == "foo.example.com"
- backend:
foo.example.com
With this configuration, I thought that a request for foo.example.com/v2/ping
would set the backend to bar.example.com
and a request for foo.example.com/v1/ping
would set the backend to foo.example.com
.
However, the backend for foo.example.com/v2/ping
was set to foo.example.com
.
This is because the request conditions are evaluated in ascending order of priority, but matching the conditions does not stop them from being evaluated.
The above request conditions are VCL as follows.
# Request Condition: api_v2 Prio: 10
if( req.http.host == "foo.example.com" && req.url.path ~ "^/v2/" ) {
set req.backend = F_bar_example_com;
}
#end condition
# Request Condition: api_v1 Prio: 20
if( req.http.host == "foo.example.com" ) {
set req.backend = F_foo_example_com;
}
#end condition
If statements
are generated as there are request conditions. if a condition with a high priority value is matched, the backend will be that one.
When setting the request conditions, you must be aware of one of the following:
- Set a condition that does not match more than one request condition
- Set priorities appropriately to ensure that multiple request conditions match the intended behavior