-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Redirect using captured pattern of original url #5
Comments
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. |
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. |
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 Second you can write instructions to control the original request. For example to change the port to 8080, write Can you test them out and let me know of any problems? |
I am afraid there are serious problems. :-( First, I tried to use the following redirect rule: Second, I tried to use the following redirect rule: |
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: How did you test [port=8080]? Did you write just that as a redirection URL? |
Fixed one issue with multiple {parameter} failing. Please test: |
I think the port loop issue is still the problem. Actually any same domain redirection may cause looping. |
Another beta release with the loop issue fixed: Any success with this version on your end? |
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: 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. |
Nice observations 👍 I'll release the beta1 for now. beta1 fixes only the greedy regular expression pattern for catching the parameter expansions. 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. |
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. |
Requested by FStl, March 9, 2017
https://addons.mozilla.org/fi/firefox/addon/requestcontrol/reviews/847635/
The text was updated successfully, but these errors were encountered: