Redirection doesn't work on https

Having a similar problem.

WP 4.1.1
Redirect version 5.0.6

In quick-redirects if I use:

/help/?data=456 –> /url-for-help-file-456/

It works in HTTP mode.

This also works:
/help/?data=456 –> https://MYDOMAINNAME/url-for-help-file-456/

If I set it like this:
https://MYDOMAINNAME/help/?data=456 –> /url-for-help-file-456/

https://MYDOMAINNAME/help/?data=456 –> /url-for-help-file-456/

The top one works, the second one doesn’t. (I know, it says not to use the full domain in there, however it does work.)

I’d like the redirect to not care what the protocol is and do the redirect anyway. The strange part is, if I reverse the order of the rules above, it’s always the first one that is executed and the second one (with the other protocol) is ignored.

One of two things is happening, either the way we have HTTPS implemented is causing one of the systems Redirect uses to be bypassed, or it stops processing rules based on the URL after the first slash and ignores the domain name. The fact that the rules change behavior when re-ordered makes me think it stops processing rules when it finds a match for after the first /.

My alternative method for doing the same thing (making help files for a program go to particular pages that don’t exist yet based on the context of the help button in the program today) is mess with mod_rewrite in htaccess.

Is there any way to get this tool to completely ignore the domain name and the protocol using just /file.htm > /file/ type redirects?

UPDATE. I think I just solved this. Continuing on the post above, if I do this:

/help/?data=456 –> /url-for-help-file-456/

AND then have a second rule UNDER the first:

https://MYDOMAINNAME/help/?data=456 –> /url-for-help-file-456/

Then; if I do :

https://MYDOMAINNAME/help/?data=456

OR

https://MYDOMAINNAME/help/?data=456

They both get redirected properly. Not sure if that will help Jakub out or not but it’s worth a try.

I think this is a data-matching on the criteria problem. The domain and protocol seem to be looked for, but not used.

I was also able to do this:

/help/?data=456 –> /url-for-help-file-456/

https://MYDOMAINNAME/help/?data=456 –> /SOME-OTHER-URL/

Making a redirect behave differently depending on the protocol.

I confirm that adding second redirection rule is working.

Hi guys,
You are both correct in that you DO need to add a second match to encompass the http and the https in this situation.

This is not the case in all instances, but only when a site is using mixed protocols (meaning that URLs can be accessed via http or https). Technically, as far as the plugin’s matching script is concerned, they are 2 completely different URLs, so they both need to be matched to be redirected.

In cases where the entire site uses https protocol, the normal redirect structure will work, so /something/ -> /somthing-else/ will work fine whether they use http or https, because the request gets redirected to https first by WordPress (or in some cases .htaccess) and then is matched on load of the page and redirected.

When people ask me about SSL, I always suggest that if the already have it installed for the site, why not just make the entire site SSL? It makes the browser feel more secure and there is no real benefit of having mixed protocols on a site. Granted, you need to fix non https URLs in content, but the overall benefit is the user’s feeling of security when on your site.

@jafiwam – thanks for spelling this out and coming back to update everyone on what you did to get it working. It helps others who may have the same issue in the future.

Warm regards,
Don