Support

Setting a different HTTP code for redirections requires Apache 2.2 or later. Trying to use a flag such as [R=301,L] instead of [R,L] in a RewriteRule on Apache 1.x or 2.0 results in a 500 Internal Server Error for your entire site. The same applies for the LiteSpeed server which only supports a subset of Apache 2.0 features in .htaccess files.

When you are asking the .htaccess Maker to regenerate your .htaccess we are trying to detect the web server make (Apache, LiteSpeed, something else) and its version. We do that by reading the SERVER_SOFTWARE environment variable, as advertised by your server software to PHP.

If you look at our code you will see that the three ways we can detect a lower version than what is required for custom redirection codes are 1. the SERVER_SOFTWARE environment variable is not set or is empty; 2. you are using a non-Apache web server software; or 3. the SERVER_SOFTWARE advertises a lower Apache version in the form "Apache/2.0".

If I recall correctly from your past tickets you are using Rochen. Rochen is using LiteSpeed, not Apache. As I said, LiteSpeed does not allow custom redirection codes such as [R=301,L] in RewriteRule. That's why you get the default [R,L] flag which results in a 301 Redirect. There is no solution to this apart, of course, from using Apache 2.2 or later. It's a limitation of the web server software, not Admin Tools.

I am confused now. First you say:

we have removed the apache version from end display.

If you are on Apache and the SERVER_SOFTWARE environment variable is empty we will detect this as non-Apache and disable all advanced features as I said.

If you are on Apache and SERVER_SOFTWARE is set to "Apache" then we assume version 2.4 or later and custom redirections are enabled.

Removing the Powered-By header, however, has nothing to do with the SERVER_SOFTWARE environment variable.

You are further complicating things by saying:

We use litespeed

Is it Apache or LiteSpeed? If it's LiteSpeed, that's why we do not include the custom redirection codes. There is no indication on if/when they added support for them in .htaccess.

Basically, you gave me conflicting information and I have no idea what is the truth for your server :/

Regarding the possibility of choosing your own Apache version (or compatibility mode): In my experience, the few people who need such an option know how to work around it. The majority of people who will change this option will do so in a misguided fashion, without reading the documentation and they will get locked out of their site. This creates an unnecessary increase in support load and a higher tension with users. So I'd much rather rely on automatic detection. If you have the option to change the SERVER_SOFTWARE environment variable set it to "Apache/2.2" and Admin Tools will create redirections with custom 301 codes.

Speaking of which, if I gave you such an option you'd probably set it to "Apache 2.4 or later" to enable "everything". Right? It stands to reason. That would cause a problem with other .htaccess features which, in this case, rely on differences between Apache 2.2 and 2.4 (different core modules, different ways to set headers etc). At best, features would not work and we'd be lost in an endless ticket trying to figure out why things tested to be working here don't work for you. At worst you'd get an immediate 500 page and my suggestion to try and disable one option at a time would get you nowhere. I hope that thought experiment demonstrates why there is no such option and we will not add one.

Regarding the missing language string, thank you for reporting it. It had been reported and already fixed but a new version has not been released yer. According to my experience, mid-July to mid-August is vacation time for most of our clients. Releasing something during that period has really bad reception. So I am waiting for September to make new releases (and going on vacation myself next week).

As I already explained, SERVER_SOFTWARE is made available through the $_SERVER superglobal. You cannot have SERVER_SOFTWARE populated but not visible in $_SERVER. So I will go on under the assumption that it’s set to “LiteSpeed”. Since LiteSpeed never bothers to provide its version and does not support the full feature set of Apache we have to detect it and support the features definitely provided by it. Custom redirection codes IS NOT one of them. Therefore you get the default redirection which is a 302.

This IS NOT about labeling something. You are asking me to always do a misdetectrion of server software which will break hundreds of sites but will work on yours. This is not going to happen as long as LiteSpeed keeps not providing its version in the SERVER_SOFTWARE environment variable and there are still older versions of LiteSpeed in production which do not support custom redirect codes. I cannot go ahead and break everyone’s sites (critical issue with no mitigation) to address a redirection code (non-critical issue with an easy mitigation).

Also, here is the thing about “this causes a 500 Internal Server Error for the entire site”. When that happens your site is toast until you, a human, go and remove the .htaccess through FTP/SFTP/control panel/whatever. You cannot have a piece of code run when the problem is that your site is dead in the water and not even static content, let alone executable code, will load at all.

Moreover, it’s not the kind of setting you would be likely to look at. Even worse, it’s the kind of setting which would break your site when you regenerate the .htaccess file after restoring your site on a different server and forgetting to change it back to something suitable for this server. We have seen this happening. How do you think we ended up with automatic server software detection in Admin Tools and the feature to automatically replace the .htaccess when restoring a site in Akeeba Backup?

Here’s a simple solution. Generate the .htaccess and then mass replace [R,L] with [R=301,L] using sed:

sed -i -e 's/[R,L]/[R=301,L]/g' /path/to/your/site/root/.htaccess

Here’s an even simpler solution. Change the SERVER_SOFTWARE to “Apache/2.2”.

Both solutions work great on your server and don’t affect anyone else’s site.

This is a non critical issue with an obvious workaround that you are already doing. Anything else would cause problems for too many users of our software. There is nothing else to say about this. Therefore this issue is now closed.