RegEx matching errors, particularly `?srsltid` strings

menubar

Using the RegEx ^(https?:\/\/|)([^\?#]*).*$|$1$2, specifically to target ?srsltid strings doesn't seem to be working. I can't find a RegEx error, and I've written a decent amount of RegEx without any issues in the past, except some noncapturing groups not being recognized on Shortcuts.app, which I solved by using the inside pipe after the https, which is why I'm using it here instead of (?:https:\/\/)?. I've tried a few variations of the RegEx, some of which have succeeded in replacing the domain, somehow, but I can't seem to get rid of this string in search results. Oddly, Kagi tends not to show other tracking parameters, so I'm not sure why this one is showing up even before the clean domain in search results.

I've verified my characters are the correct unicode.

Proper replacement. For example: https://dangkeebs.com/?srsltid=abc123 to replace to https://dangkeebs.com/ using the aforementioned RegEx.

pixel

menubar

The problem here is related to some rules on our end, not necessarily the regex itself.
We currently do not support fully removing query parameters (or path).

This was done to allow simple things like reddit.com|old.reddit.com without the end user having to worry about it.
Unfortunately at this point we can't necessarily change that default behaviour since it would be a breaking change, but we could potentially add an option (or multiple) that would allow you to fully drop those if you so choose.

(a hacky workaround is you can use something like ?1 in your replacement to overwrite the query params, which would remove any existing ones, and just use that - but obviously this is not ideal)

If you would like to see this option a thing, then perhaps we can convert this post into said feature request.

z64

Hey there! We will look into this more closely, but as a heads up, we are deploying default filtering of ~100 common tracking parameters this week, including srsltid; so hopefully a rule like this won't be necessary anymore! 😄

This should go live sometime between today and Thursday.

menubar

z64 thanks. I would still like to know what's going wrong with the match filter or if I'm somehow not following PCRE because it would be good to know in the future. I saw you commented on another thread something related to a bug in Kagi's RegEx involving slashes, and I was wondering if this was somehow related.

I'm interested in knowing why I was getting matchₙ₋₁ replacement issues because that would affect any future RegEx also

And to clarify, although the RegEx examples don't use backslashes except within groups, traditional backslash usage is still accepted by Kagi's PCRE implementation?