Redirect using captured pattern of original url

[tumpio]

Requested by FStl, March 9, 2017

Is there any way to redirect requests by retaining or capturing the matched patterns?

For example, redirect http://www.example.com/* to http://www.example2.com/* so that the path specified after example.com/ is copied after example2.com/

It is not so useful otherwise. :-(

https://addons.mozilla.org/fi/firefox/addon/requestcontrol/reviews/847635/

[F-Stl]

Thank you for opening this issue. It would be great if you can add this feature.

I also request you to check this thread I created here - https://discourse.mozilla-community.org/t/infinite-loop-when-redirecting-to-a-different-port-on-same-domain/14326/4 - even if you don't add explicit support for port redirection, at least add the infinite-loop check in your code as discussed in this thread.

[tumpio]

yes, the redirection support is very basic at the moment. There is much to improve it. Thanks for letting me know about the port loop issue, I opened another issue for it too to remind me about it.

[tumpio]

I released version 1.4.0 that is soon available in AMO once Mozilla has reviewed it.

In this version there is now two ways to redirect based on the original request.

First is by using parameter expansion in the redirection address. The available parameters are URL object's string type parameters. For example to access the hostname of the original request write https://{hostname}/some/new/path as redirection address. It is also possible to do some few string manipulations. Check the help page for them.

Second you can write instructions to control the original request. For example to change the port to 8080, write [port=8080] as redirection address.

Can you test them out and let me know of any problems?

[F-Stl]

I am afraid there are serious problems. :-(

First, I tried to use the following redirect rule:
https://{hostname}:8080/{pathname}{search}{hash}
But when I tried to load my website, it seemed to only load the HTML and no CSS or any images. And if I try to click on any link, it just loads the home page only (again without CSS/images). Further, I'm not even sure if the basic HTML is actually loaded from 8080 or 80, because Firefox's address bar shows the URL as:
https://{hostname}

Second, I tried to use the following redirect rule:
[port=8080]
This time, not even the basic HTML loads but instead I get the following Firefox error:
The page isn't redirecting properly. Firefox has detected that the server is redirecting the request for this address in a way that will never complete. This problem can sometimes be caused by disabling or refusing to accept cookies.
But at least in this case, Firefox's address bar shows the URL as:
https://{hostname}:8080

[tumpio]

Ah, It would help me if you could test while I fix these issues. Clearly something going bad.

Can you test it with only one {parameter}, for example:
https://{hostname}

How did you test [port=8080]? Did you write just that as a redirection URL?

[tumpio]

Fixed one issue with multiple {parameter} failing.

Please test:
https://addons.mozilla.org/fi/firefox/addon/requestcontrol/#beta-channel

[tumpio]

I think the port loop issue is still the problem. Actually any same domain redirection may cause looping.

[tumpio]

Another beta release with the loop issue fixed:
https://addons.mozilla.org/fi/firefox/addon/requestcontrol/#beta-channel

Any success with this version on your end?

[F-Stl]

Sorry for the delay in response, it took me a while to figure out exactly what is going on.

The root cause of the problem is that websites may either be coded or configured such that the Location header in 301 or 302 redirects do not take the server port into account. For example, a PHP script may have a line like the following:
header('Location: https://' . $_SERVER['SERVER_NAME'] . URL_PATH . 'xyz.php');
whereas, ideally, it should be:
header('Location: https://' . $_SERVER['SERVER_NAME'] . ':' . $_SERVER['SERVER_PORT'] . URL_PATH . 'xyz.php');

Something like this is the case with a large part of my website, including the home page. However, there are certain parts of my website that are correctly coded and thus work perfectly with the add-on (versions 1.4.0 and 1.4.1beta1).

Now, I studied the changes you made in beta2: a map of request.url => redirectUrl.href is maintained, and if a mapping already exists then the add-on returns null, which means the request.url is carried out as if the add-on didn't exist. This is a problem because even legit pages (those that don't cause redirect loops) are redirected only the first time they are visited! So beta2 is actually a regression!

So, I think you should revert to the code of beta1 and release that, and maybe document the problem I described as a known/wontfix issue. In any case, Firefox itself detects and terminates the redirect loop after about a dozen cycles.

[tumpio]

Nice observations 👍 I'll release the beta1 for now.

beta1 fixes only the greedy regular expression pattern for catching the parameter expansions.
beta2 was something from back of my head at attempting to catch the redirection looping. but yeah.. it would have to record the attempts over period of time and this I guess is what Firefox is doing.

It would be nice if you can continue to test the redirection rules. I'm also very open for code/idea contributions for this add-on.

[F-Stl]

I will be using this add-on regularly (once 1.4.1 is released) with my own website. So the testing will happen naturally.

By the way, are you aware of this Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1345893

This bug was driving me nuts yesterday, because I was looking at the Network tool and seeing pairs of connections for both the original and redirected requests.

But even more annoying is that this bug won't be fixed in 52: https://bugzilla.mozilla.org/show_bug.cgi?id=1345893#c43

I prefer to stay on the ESR channel, but this bug may force me to switch to the normal release channel.