haha not a problem at all, I use this word all the time to refer to temporary fixes. I’m just not certain it will be temporary this time around. It may be the case that Cloudflare APO team decides that the reported behavior is expected, we’ll have to wait an see.
That’s explained by @michael’s response above and the documentation it points to.
All good!
Thanks, of course the response above… I checked and to test did a curl
❯ curl -sI "https://onlinetips.com/?ref" | egrep '^HTTP/|cf-|location|content|cache'
HTTP/2 301
content-type: text/html; charset=UTF-8
location: https://www.onlinetips.com/
cf-ray: 7ab781b439c55d33-LIS
cache-control: max-age=3600
cf-cache-status: MISS
cf-apo-via: origin,resnok
cf-edge-cache: cache,platform=wordpress
report-to: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=eaeqpuX8LQJ%2B%2FnMvF8aGAUDnkdyU78hZ5MU%2B%2BC4z1J6RxM5tJMF06U89Y7GSJ2raORj9UceVshB98sO8V47vxyQVLJtoPG5hR%2FVTfosbSDBBE8X6uqJKxoc4YFCENVKJf%2Btgn6BXbZovID6CZQ%3D%3D"}],"group":"cf-nel","max_age":604800}
nel: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
❯ curl -sI "https://www.onlinetips.com/?ref" | egrep '^HTTP/|cf-|location|content|cache'
HTTP/2 200
content-type: text/html; charset=UTF-8
cf-ray: 7ab78276781c94f4-LIS
cache-control: max-age=2592000
cf-cache-status: HIT
cf-apo-via: tcache
x-cache-handler: cache-enabler-engine
report-to: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=qQFaalA%2B7azqdq%2FPhOc1efLr29LoDR%2BWb4ZGeEZWQCIlbLsCo6a%2Fi9Pb3Wj5gNJdtwJ%2Bchl5VkEIdAEwfi%2B6bLP%2BTrWcg5S7QG%2FAso0nFmZNyduCrQDItpGODxe6WBuonZG7f7ynHagngMzqIKxYOGE%3D"}],"group":"cf-nel","max_age":604800}
nel: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
“ref” being of the cached ones and if there is a redirect from “non-www” to “www” it goes from HIT to MISS
When trying “wordpress” one of the query parameters that bypass cache
❯ curl -sI "https://www.onlinetips.com/?wordpress" | egrep '^HTTP/|cf-|location|content|cache'
HTTP/2 200
content-type: text/html; charset=UTF-8
cf-ray: 7ab78ac0ce1d489d-LIS
cache-control: max-age=2592000
cf-cache-status: BYPASS
cf-apo-via: origin,qs
cf-edge-cache: cache,platform=wordpress
report-to: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=G1KZddj0ISZu24mrMwcp0vN44VPfaKzR9SoP7G%2F8r5AEq0kpKnzzi7MdlmhbwU0efnYybD5TMmcc4BQ28rqKkq2MSaA1aNFn%2B%2B79UiLhk%2FJZpRCDd6SV%2BJW%2FS8%2FAxDY9%2BaxXMxq%2FCOiVnY2YkIM5Xu0%3D"}],"group":"cf-nel","max_age":604800}
nel: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
~
❯ curl -sI "https://onlinetips.com/?wordpress" | egrep '^HTTP/|cf-|location|content|cache'
HTTP/2 301
content-type: text/html; charset=UTF-8
location: https://www.onlinetips.com/?wordpress
cf-ray: 7ab78af22e0bda7e-LIS
cache-control: max-age=3600
cf-cache-status: BYPASS
cf-apo-via: origin,qs
cf-edge-cache: cache,platform=wordpress
report-to: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=uTRtPN56rJSY3hIvuI8NjMSIgG8puyxmJ3EYKqnGZNlEB4NbSHR2Ee8DIsV%2Bo%2BUGAo9Roq2sHsOOfCPI1%2Fve37k0pi5CyPAZIBculElsuu0mLiJj2oewQFwolWPy9Saplnzetyu2VMgoc%2FP5oQ%3D%3D"}],"group":"cf-nel","max_age":604800}
nel: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
it is always BYPASS… even with the redirect of “non-www” to “www”.
I will look into your Transform Rule for the smaller website with APO enabled.
All expected behavior. The 301 has a shorter TTL and therefore you’re more likely to get a MISS. The 200 gest a HIT, as it’s actually fetching the cache from example.com/ and not example.com/?ref.
wordpress is not on the list of query parameters, but on the second list, of cookie prefixes. These cookies will lead to BYPASS, as expected.
Okay, understood… but then, on the first example with “?ref”, all expected behaviour, but it loses the query parameters on the redirect. Should it?
Because with “?wordpress”, like you said it’s on the second list of cookie prefixes, it keeps the query parameter even with the same redirect…
Hi again,
So I went ahead and disabled APO on the smaller website.
Cleared cache and uninstalled CF plugin on wordpress.
Losing the utms with a redirection just stopped when doing this.
Leaving curl for reference
curl -sI "https://onlinetips.com/?utm_source=facebook"
HTTP/2 301
date: Wed, 29 Mar 2023 17:10:22 GMT
content-type: text/html; charset=UTF-8
location: https://www.onlinetips.com/?utm_source=facebook
expires: Wed, 29 Mar 2023 18:10:23 GMT
cache-control: max-age=3600
x-redirect-by: WordPress
vary: Accept-Encoding
cf-cache-status: DYNAMIC
report-to: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=vSHlqrA0xMlyDgaU643Oal%2Ftz60tfI5%2BUGUCBlc%2FuziKxKr0hUS0idHarsxfhCLMbqU4FefoAL3z8nfZWMmZUQW%2F3Ht0dityI4zOgsgbEqP2DC3D1pZH2CTgVF0psCHs4ymMETSRiIAH3yDOtQ%3D%3D"}],"group":"cf-nel","max_age":604800}
nel: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
server: cloudflare
cf-ray: 7af9b9d8f98b9501-LIS
alt-svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400
We don’t have an update for you yet, but I wanted you to know we are still reviewing and looking at this.
I was able to talk to the team they are conitnuing to investigate. We likely will have no updates until next week though.
Hello,
I believe I’ve found a part of my issue that is still occurring.
When APO is enabled, www.example.com always redirects to example.com, and removes any URL query params, even non-GCLID/utm_* queries. For instance, https://www.example.com/?test=test redirects to https://example.com.
I still have the URL rewrite transformation rule enabled that was recommended by cbrandt, which triggers for example.com URLs with no "/" before the query.
I’ve tried making Page, Transform, Origin, or Redirect rules to redirect www.example.com/* to https://example.com/$1 but I was not able to get any to work, though I can’t guarantee that all rules were made perfectly.
I have confirmed that disabling APO stops this issue from happening.
Hi,
This has already been reported by the other users whose issues were merged into this thread. Please refer to the same post where I suggested you could use a Transform Rule for cases where there was a missing trailing slash, and check the part where I talk about the 2 possible solutions for the canonical redirects.
As for how to implement these redirects, forget about Page Rules or Origin Rules. You should either create Redirect Rules (preferred for SEO reasons) or follow the example I gave for a Transform Rule. If you are having difficulties crafting the correct rule, please post a screenshot of what you have tried so that this community can help you with that.
When I open the link https://aseure.uk/?utm_source=test&utm_medium=paid_social&utm_campaign=test&utm_content=test&utm_term=test on incognito, it strips the UTM tags and redirected with www.
Has this issue been resolved yet?
I just noticed that all of my traffic for the last 3 weeks has been labeled as “direct” within google analytics, despite it all coming from Google Ads.
All UTM parameters were tripped from all google ads clicks.
Thank you.
Actually, turns out it was an SEO plugin (All-in-one SEO), which was stripping all parameters from the URL.
Edit: Actually, looks like it was a combination of things, but the main one was a Redis Object Cache plugin on Cloudways.
Once I disabled this, all other plugins were fine to keep enabled.
P.S. as with anything, maybe there are other factors. Will update if anything changes.
Hello everyone,
Thanks for your patience on this. The last month has been pretty busy on our side, so I didn’t have much time to look into it until recently.
Yesterday, I think I identified the root cause of the issue. The possible fix is currently being rolled out, and should be deployed everywhere in a few hours. My initial tests against my own zone on already fixed servers are showing that utm* parameters and other allowlisted query parameters are no longer removed.
If you see my message after 2023-04-12T17:00:00Z, you should expect the fix to have been deployed everywhere and could test your zone with APO enabled again and without the Rewrite URL Transform Rule.
Let me know if you still experience issues, I’ll continue to look into it on a case-by-case basis.
I am sorry, I was out sick and just have gotten out of my backlog.
Fortunately we do have the update now!
Great news, thank you for taking the time!
I have activated APO and after clearing caches and everything, close monitoring seems the issue is solved. utm parameters are not lost.
One thing though , maybe you can clarify… when on the browser I see a 301
But on a curl, it shows a 520?
This is unrelated to this topic, because if a domain for some reason is returning a 520 you’ll get the same error if you curl with or without the UTM parameter. I’ve tested repeatedly with an APO test domain and I’m getting the expected 301/200 responses.
Please feel free to check the documentation on the 520 error and if you think there’s any reason this is Cloudflare-related, open a separate topic.
Yep, Just checked. That issue is there no more. Now UTM tags are staying there after the redirection.
Thank you.
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.
