Support

This is a bug in your server setup. Ask your host to REMOVE the non-existent custom error pages from the vhost configuration. If you are hosted on a cPanel-powered server you most likely can do it yourself. Just ask your host.

FYI this server configuration issue also affects sites with the stock Joomla! and WordPress .htaccess files when there is a password-protected directory.

I can tell you exactly why they are connected. I wasted two days of my life tracking down this issue...

When you have a password protected directory, Apache needs to first load the error document it will display if you provide the wrong –or none at all– username and password. This is the 401 error document ("Authorization required").

Since you've set up a custom ErrorDocument in your virtual host configuration, Apache is trying to load it. However, your 401.shtml file doesn't exist. Apache sees that and tries to figure out what to do next.

A reasonable, sane person would say "OK, you didn't find a custom message so why don't you try the default one". But NOT Apache. Remember that its named is derived by its moniker back in the '90s: "a patchy server". Yeah. Apache will actually try to follow the redirections set in your .htaccess file.

Since Joomla! 3.3.6 (and Admin Tools 3.4.0 implementing the same changes in .htaccess Maker) there was a line dropped from the Joomla! .htaccess file. That line would only redirect requests to Joomla! IF AND ONLY IF the extension matched one of .htm, .html, .raw, .feed and a few others. When that line was present the redirection yielded no result and Apache would wise up and display the default 401 Authorization Required message.

However, now that this line is missing –exactly as happens with every other PHP-based CMS such as WordPress and Drupal– Apache is asking Joomla!'s index.php to handle the request. Joomla! sees the invalid "401.shtml" URL alias being passed to it and has no friggin' clue what to do. So it returns the semantically correct HTTP 404 Not Found reply and a page stating "404 Category not found". Apache sees that and thinks "oh, I broke something, let's show this obviously erroneous page instead of letting the poor user try logging in to the password protected directory – and who gives a flying f**k if I confuse the crap out of him". Gargh!

FYI, I've figure out a solution for Admin Tools. I've also reported my findings to the Joomla! Production Leadership Team. They are thinking how to best handle this. It's obviously a problem with Apache doing something stupid. The question is how to best handle it: apply an architecturally incorrect solution in PHP which might be forgotten and removed accidentally in a couple of years OR just document Apache's crazy behaviour? I chose the former. I'm betting Joomla! will opt for the latter.

I thought the same as your host until 3 days ago, to be honest. Then I read the fine manual which states:

Note that when you specify an ErrorDocument that points to a remote URL (ie. anything with a method such as http in front of it), Apache will send a redirect to the client to tell it where to find the document, even if the document ends up being on the same server. This has several implications, the most important being that the client will not receive the original error status code, but instead will receive a redirect status code. This in turn can confuse web robots and other clients which try to determine if a URL is valid using the status code. In addition, if you use a remote URL in an ErrorDocument 401, the client will not know to prompt the user for a password since it will not receive the 401 status code. Therefore, if you use an ErrorDocument 401 directive then it must refer to a local document.

There is a corollary to the last two sentences: if the ErrorDocument 401 does not return an HTTP 401 code Apache will not know to prompt the user for a password. What the documentation doesn't explicitly state is that this also applies to LOCAL DOCUMENTS.

What it also doesn't state is that Apache follow redirects. From the same fine manual:

URLs can begin with a slash (/) for local web-paths (relative to the DocumentRoot), or be a full URL which the client can resolve.

One would think that if a local document (starting with /) is specified then it has to be an existing file or it will simply not be found. Well, reading it more carefully we notice that it says "local web-paths", NOT "local documents". Since it is a web-path, redirects DO apply on it.

Feel free to forward this reply to your host. It may save them a lot of head scratching in similar cases. The wording in Apache's manual is a bit deceiving :(