If Cloudflare has already cached the response for the URL https://example.com/, I want to avoid getting MISS responses for subsequent requests, such as
https://example.com/?query=1
https://example.com/?query=2
https://example.com/?query=3
Ignore Query String appears to work only for static files.
Is there any workaround without using Redirect and Worker? Thanks in advance.
The easiest fix
(not http.request.full_uri contains "https://www.example.com/?s=" and not http.request.full_uri contains "https://www.example.com/wp-content/" and not http.request.full_uri contains "https://www.example.com/wp-includes/")
Created a caching rule to turn on
Note: I added this rule in the last.
I hope this helps anybody looking for handling this case.
Just to be clear, the option Ignore Query String appears after clicking on Cache Key.
Depending on the WordPress theme, the /s= search query string may appear after paths other than the home page. So, instead of
not http.request.full_uri contains "https://www.example.com/?s="
you should use
not starts_with(http.request.uri.query, "s=")
And since there are other core WordPress paths that you should avoid dropping the query string for, such as the WP REST API /wp-json/ path, redirects from /wp-login.php etc,
Instead of
and not http.request.full_uri contains "https://www.example.com/wp-content/" and not http.request.full_uri contains "https://www.example.com/wp-includes/")
perhaps you could try:
and not starts_with(http.request.uri.path, "/wp-"
Also, it would be safer if you also set the cookie for logged in users as condition for the rule, to avoid breaking your site when running internal /wp-admin/ pages that may call the front-end URL with query strings. This is the case when you visit WP Dashboard > Appearance > Customize.
and not http.cookie contains "wordpress_logged_in"
Last, but not least, be ready to be surprised. With the infinite combination of constantly-updating plugins and themes, and their configurations, it’s best to test and retest all features of your website before implementing this Ignore Query String setting. Some plugins may need a special front-end query string to perform their magic.
In the context of a WordPress installation, it’s very difficult to prevent 404s being used to attack a website from the cloud, unless of course your site is small and all paths fit in one Firewall Rule.
If you already protected your site against query string attacks, you’d need to provide Cloudflare with a list of paths that it should not block/challenge, using the is in operator. For example:
(not cf.client.bot and not http.request.uri.path contains "/wp-" and not http.request.uri.path in {"/path1/" "/path2/" "/path3/" "/etc/etc/"})
Firewall Rules have a limit of 4KB each, so for small websites with static content (no comments and things like that), it may be possible, but for a WordPress blog with /category/, /tag/, /archives/, /2023/02/ and other derivative path elements, it may be challenging.
(BTW, the rule on your screenshot has URI in the first visible element, when it should be Path. And this condition makes the last one unnecessary.)
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.
