- Rule expression:
http.host == "example.com" and starts_with(http.request.uri.path, "/downloads/") - Host header > Rewrite to:
assets.example.com
Troubleshooting
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:
<OTHER_RULE_CONDITIONS> and not starts_with(http.request.uri, "/cdn-cgi/challenge-platform/")Before a certificate authority (CA) will issue a certificate for a domain, the requester must prove they have control over that domain. This process is known as domain control validation (DCV).
If you are using HTTP DCV and also have Single Redirects set up in your zone, consider excluding the /.well-known/* path from your rule to avoid DCV issues. For details and other resources refer to the SSL/TLS documentation.
Cloudflare may remove the Content-Length header from responses delivered to website visitors. If the visitor must receive the Content-Length header, configure the origin server to include a cache-control: no-transform HTTP header in the response.
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:
If you configure a new URL rewrite with the following configuration:
- Rule expression:
http.host == "example.com" and starts_with(http.request.uri.path, "/downloads/") - Path > Rewrite to > Dynamic:
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
- Rule expression:
http.host == "example.com" and starts_with(raw.http.request.uri.path, "/downloads/") - Path > Rewrite to > Dynamic:
regex_replace(raw.http.request.uri.path, "^/downloads/", "/")
Origin rule
- Rule expression:
http.host == "example.com" and starts_with(raw.http.request.uri.path, "/downloads/") - Host header > Rewrite to:
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.