Personally it is much better when switching from http to https to use an .htaccess rule to redirect the urls. Using the redirect component just to switch between http and https is very inefficient and resource intensive

@brianteeman
I agree. But this isn´t really the case or the reason for my topic here.

Maybe I add this additional info...

Years ago the URL was:
http://www.domain.com/en/my-old-url.html

Then the website was switched to SSL:
https://www.domain.com/en/my-old-url.html
(without .htaccess rule because Joomla itself did it perfect by use force_ssl)

After that the URL changed to:
https://www.domain.com/en/my-new-url.html

As you can see this is a mix out of http/https switch (a while ago) and a redirect to "real" new urls (later).

So, even if there would be a 301 .htaccess rule it would be two redirects.

1. by htaccess
2. by com_redirect

This is why I think that (at least) a relative URL should redirect both – http and https.

Got me?

The problem is that technically http and https are two different domains. It is perfectly allowed and possible to have http://www.example.com/page1 and https://www.example.com/page2 as completely different content

@brianteeman
I see what you mean. Absolutely correct.

But if "force_ssl" is enabled for the whole website (status 2) this is not the case as well, tho?
Because Joomla! itself will redirect all urls to "https" in any way when it is enabled.

Now the redirect plugin always use the current scheme for the relative "old_url".
So all "old" redirects will stop working because the used scheme/host depends on which scheme/host the website will be accessed.

What I thought about was something like this...

if($app->get('force_ssl', 0) === 2):
// handle scheme depending on "force_ssl"; use http AND https as scheme for the redirect source
else:
// handle scheme like now; use current scheme
endif;

This should work for both "old_url" and "new_url" without any backward compatibility problems.

@NickSdot thanks for your first Issue and your clear Comments.

The force SSL option enforces the current URL being HTTPS before we try to route the current request. So the request isn't running far enough to know that the current URI will result in a 404. The same issue will happen if you force HTTPS with a webserver directive (i.e. changes in .htaccess) but don't use the webserver to handle redirecting old URLs as well. So the redirect plugin being unaware of scheme is OK because it won't actually run on a forced HTTPS site (either by Joomla or webserver config) until after a HTTP link has been redirected.

The only possible way to avoid the double redirect coming from Joomla code is to delay the redirect to a point after routing has been completed, but that seems like an inefficient use of server resources to me (a redirect like that should be performed as early as possible in the request, which is why the webserver handling it is the best option).

@mbabker
Not sure if I get you right.
If I understand you correctly then what I described in "Case 2.1" should not work at all – because the redirect to "https" should happen far way before.

If I add the absolute URL "http://www.domain.com/en/my-old-url.html" as "old_url" the redirecting behavior is as follows:

Case 2.1

1. access URL http://www.domain.com/en/my-old-url.html (no SSL)
2. 301 redirect to httpS://www.domain.com/en/my-NEW-url.html

But it is working. Isn´t it?

Can you please point me in the right direction if I get something wrong?
Thanks!

I don't know the internals of how the plugin is determining a redirect, but if you're using an absolute URL then it would make sense that http and https schemed URLs are checked separately as explained by Brian. My main point though is the force SSL check/redirect are happening before we try to parse the URI and route to a component, so when you hit the redirect plugin you are already past that point.

Set to "closed" on behalf of @jwaisner by The JTracker Application at issues.joomla.org/joomla-cms/18161

Closing as this as it could not be confirmed as a bug.