Redirect Rules don't handle URL query string correctly

quinncom

I noticed Redirect Rules have some unexpected behavior for URLs that contain query parameters. For example, I'm trying to rewrite https://www.youtube.com/watch?v=mUCkDmcxBzo to https://www.youtube.com/embed/mUCkDmcxBzo. No matter what I try, the resulting URL always contains the original query string, like this:

https://www.youtube.com/embed/mUCkDmcxBzo?v=mUCkDmcxBzo

Or like this:

https://www.youtube.com/embed/?v=mUCkDmcxBzo

Steps to reproduce:

Create a Redirect Rule containing ^https://www\.youtube\.com/watch\?v=|https://www.youtube.com/embed/
Search for a YouTube video, e.g., mUCkDmcxBzo site:www.youtube.com.
This search has one video result. Its URL is replaced with: https://www.youtube.com/embed/?v=mUCkDmcxBzo which is incorrect.

Expected behavior:
The URL to the video in the example search should be replaced with: https://www.youtube.com/embed/mUCkDmcxBzo.

Debug info:
Edge 119
macOS 14.1
Country/Region=International
Connected to: US-EAST
Network latency: 245ms
All Services Operational

Image/Video:
Screenshot showing the incorrect replaced URL for the example search:

Vlad

quinncom I think we may not be rewriting links in the videos wiget which is what may be cauing this problem. We will check. Otherwise have you verified your regex works in an online regex editor?

z64

Hi quinncom ,

The behavior you are running into is something we do in order to help keep redirect rules simple.

Basically we have a check that goes like:

Did the original URL have query parameters?
Are there no query parameters on the rewritten URL?
Then, transfer the original parameters onto the rewritten URL

This allows you to write extremely simple rules, such as: youtube.com|piped.moomoo.me
And the path & parameters are all maintained without you having to write a more complicated expression, just to preserve the path & parameters.

And looking at the rules our user's have created, it seems that many of them take advantage of this - or in other words, if we were to change this, it may break a number of user's rules.

An argument could be made for adding some kind of option for these kinds of things, but given that

The pattern in your other example produces a URL that works as intended (correct me if I'm missing something)
Lack of reports or other feedback on this ticket
Added complexity when creating rules

we will mark this as nofix for now.

I am open to hearing other examples where this isn't working for you, or if you have other suggestions - we can reopen it.

quinncom

Here's another example:

Create a Redirect Rule containing: ^https://www\.youtube\.com/watch\?v=([\w-]+)|https://www.youtube.com/embed/$1
Do the same search as above.
The replaced URL is https://www.youtube.com/embed/mUCkDmcxBzo?v=mUCkDmcxBzo which is wrong (notice how the Redirect Rule did replace as expected, but it also appended the original URL query string.

The correct replaced URL should be: https://www.youtube.com/embed/mUCkDmcxBzo

feedbackhax

Ignore this...

feedbackhax

Vlad i've played with it too it's hella weird behaviour

quinncom

Hello @z64,

Thanks for the details of how the rewrite rules work internally (please add this to the docs).

Because of the test for query parameters on the rewritten URL before copying the original URL query params, I can simply add any query parameter to the target URL to prevent this issue. Using my second example, if I add ?t=0 to the target URL, the final URL becomes: https://www.youtube.com/embed/mUCkDmcxBzo?t=0, which is acceptable (it's only a minor aesthetic burden).

A more complete solution would be to allow using regex flags that configure how Kagi redirect rules function, separated by a second vertical bar. For example, to disable this behavior of copying the original URL params, perhaps use a P flag like this:

^https://www\.youtube\.com/watch\?v=([\w-]+)|https://www.youtube.com/embed/$1|P

Thanks!

Vlad

quinncom If not added already please feel free to amend the docs, it is open source.