Example
- Rule expression:
http.host == "example.com" and starts_with(http.request.uri.path, "/downloads/")
- Host header > Rewrite to:
assets.example.com
If you are issuing a challenge for a given URI path that has one or more Rules features enabled, you should exclude URI paths starting with /cdn-cgi/challenge-platform/
in your rule expressions to avoid challenge loops.
For example, define a compound expression for your rule using the and
operator and the starts_with()
function:
If you rewrite a URI path using a URL rewrite, this may affect other Rules features executed later — such as Origin Rules — if they include the URI path in their filter expression.
Consider the following origin rule configuration:
Example
http.host == "example.com" and starts_with(http.request.uri.path, "/downloads/")
assets.example.com
If you configure a new URL rewrite with the following configuration:
Example
http.host == "example.com" and starts_with(http.request.uri.path, "/downloads/")
regex_replace(http.request.uri.path, "^/downloads/", "/")
The origin rule will no longer match /downloads/*
paths, since URL rewrites run before Origin Rules and the URI path will be rewritten from "/downloads/"
to "/"
.
To prevent this situation, use raw fields in your rule expression. Raw fields are immutable during the entire request evaluation workflow, and they are not affected by the actions of previously matched rules.
In the current example, you could use the raw.http.request.uri.path
field in both rules:
URL rewrite
Example
http.host == "example.com" and starts_with(raw.http.request.uri.path, "/downloads/")
regex_replace(raw.http.request.uri.path, "^/downloads/", "/")
Origin rule
Example
http.host == "example.com" and starts_with(raw.http.request.uri.path, "/downloads/")
assets.example.com
This way, the two rules will work as intended. Additionally, this allows you to use the same expression in the two rules, even when the first rule is updating the URI path value.
For a list of raw fields, refer to the Fields reference page.