Query string loss during cached trailing slash redirects when using CacheKeyModify

[eriksth]

Hi,

when using the "Drop Query String" feature (e.g., -qs:utm_source or -qs:gclid), the LiteSpeed Cache engine strips these parameters to find a cache match. If the requested URL (without a trailing slash) triggers a WordPress redirect to the version with a trailing slash, the cached redirect might be different from the url the user requested.
I think by default, this is the case for
fbclid, gclid, utm*, _ga

Steps to Reproduce:

• Add Drop Query String test_param
  Visit example.com/page (no slash, no param). WordPress redirects to domain.com/page/. LiteSpeed caches this redirect.
• Visit domain.com/page?test_param=123.
  Observed Result: LiteSpeed matches the cached redirect for /page and sends the user to domain.com/page/. The ?test_param=123 is lost.
  Expected Result: The user should be redirected to domain.com/page/?test_param=123.

Environment:

Plugin: LiteSpeed Cache for WordPress
Server: OpenLiteSpeed
Feature: Drop Query String / CacheKeyModify

[qtwrk]

https://github.com/qtwrk/lscache_wp/blob/ae85e11dcd53c342aefc76f7639d3ac20a743c75/src/control.cls.php

could you please try this file and see if it works as you expected ?

[eriksth]

https://github.com/qtwrk/lscache_wp/blob/ae85e11dcd53c342aefc76f7639d3ac20a743c75/src/control.cls.php

could you please try this file and see if it works as you expected ?

i will try tomorrow morning, thx