• Please be aware: Kaspersky Anti-Virus has been deprecated
    With the upgrade to Plesk Obsidian 18.0.64, "Kaspersky Anti-Virus for Servers" will be automatically removed from the servers it is installed on. We recommend that you migrate to Sophos Anti-Virus for Servers.
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Forwarded to devs Custom 403 error document never shown for document root

Kaspar

API expert
Plesk Guru
Username:

TITLE


Custom 403 error document never shown for document root

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE

Plesk 18.0.51
CentOS 7.9

PROBLEM DESCRIPTION

When a custom 403 error document is configured for a domain trough either a .htaccess file or the Additional Apache directives it's never shown when there is no index file for the document root of a domain. Instead the default apache welcome page is always shown (together with a 403 http response code of course). In other scenarios that trigger a 403 error within the document root, for example when the SSLRequireSSL directive is used, a custom 403 error document isn't shown either.

Just to be clear, this issue only relates custom error documents for 403 errors in the document root of a domain.

I am aware that showing the default apache welcome page when there is no index file present in the document root and directory listing is prohibited is (or used to be) common behavior for Apache. However I would expect that a custom 403 error document to take precedence over the default apache welcome page as an error document.

STEPS TO REPRODUCE

Apache is used in Proxy Mode.

Scenario 1: no index files
1) Create domain in Plesk
2) Remove any index file from the document root of the domain
3) Create a custom error document for 403 error (403.html) in document root
4) Create .htaccess file add ErrorDocument 403 /403.html rule to file
5) Access domain via browser, notice how default apache welcome page is shown instead of custom error document

Scenario 2: SSLRequireSSL
1) Create domain in Plesk
2) Create a index.html file
3) Create a custom error document for 403 error (403.html) in document root
4) Create .htaccess file add code below to file
Code:
SSLRequireSSL

ErrorDocument 403 /403.html
5) Disable "Permanent SEO-safe 301 redirect from HTTP to HTTPS" option from example.com > Hosting Settings
6) Access domain via unsecured connection (http) in browser, notice how default apache welcome page is shown instead of custom error document

ACTUAL RESULT

In all scenarios concerning the document root of a domain the default apache welcome is used as the 403 error document.

EXPECTED RESULT

A custom 403 error document should take precedence over the default apache welcome page as an error document.

ANY ADDITIONAL INFORMATION

Adding ProxyErrorOverride on to the Additional Apache directives doesn't seem to have any effect.

YOUR EXPECTATIONS FROM PLESK SERVICE TEAM

Confirm bug
 
Last edited:
403 would be "forbidden", but in the case of a missing index document, this is not a forbidden access, bus a missing index document. This does not need to mean that access is prohibited. For example the web server could have the DirectoryIndex option set so that instead a directory listing could be displayed. It could also be thinkable that only the index file is missing (by design), but other files could be addressed directly and the user does not want the requestor to know.

A different case where a 403 is triggered is when access is indeed forbidden by permission, e.g. if the document root directory is associated with group psacln instead of psaserv.

I have one more argument ;-) : To locate such error documents in document root is not best practice, because when the web server cannot access the directory (e.g. in above mentioned case of wrong permissions), it can also not display the 403 error document for that case. That would be correct and expected. This scenario also applies to the second case from the report where SSLRequiredSSL is used. If the condition is not fulfilled, the web server would need to load the error doc from the website, but it cannot do that, because the condition is not fulfilled to load files from there.

I think the root cause is the wrong path for the error document. It needs to be located outside document root. That is also the Plesk default (the separate error docs directory). The same issues as described above should then not occur.
 
Thank you for your feedback. Based on your response it looks like my bug report created some confusion so I've amended it with additional info.

403 would be "forbidden", but in the case of a missing index document, this is not a forbidden access, bus a missing index document. This does not need to mean that access is prohibited. For example the web server could have the DirectoryIndex option set so that instead a directory listing could be displayed. It could also be thinkable that only the index file is missing (by design), but other files could be addressed directly and the user does not want the requestor to know.
That's correct. In Plesk the directory index Options directive is configured to prohibit directory listing by default. As result, when no index file is present a 403 error is returned. Which is expected and correct behavior. Other files in the same directory are be accessible without any issue.

[...] I have one more argument ;-) : To locate such error documents in document root is not best practice, because when the web server cannot access the directory (e.g. in above mentioned case of wrong permissions), it can also not display the 403 error document for that case. That would be correct and expected. This scenario also applies to the second case from the report where SSLRequiredSSL is used. If the condition is not fulfilled, the web server would need to load the error doc from the website, but it cannot do that, because the condition is not fulfilled to load files from there.

I think the root cause is the wrong path for the error document. It needs to be located outside document root. That is also the Plesk default (the separate error docs directory). The same issues as described above should then not occur.
I agree that the document root is not best location for storing error documents/pages. However I don't think it's 'wrong' and causes any issue with loading the error document. I did tested this issue extensively on multiple servers, with the custom error documents in various directories. But none worked :( Mind you, the default Plesk 403 error document, which is stored in the error_docs directory outside of the document root (in the domains home directory) isn't loaded/used either when no index file is present in the document root. Which one would expect to be shown.
 
Last edited:
O.k., the argument, that the central error_docs 403 document is not shown either, is striking. Let's hear what developers think about it, forwarded as ID [PPS-14165].
 
No problem, with asking questions I try to also make it clearer to developers whether it is a bug or a missing feature or maybe sometimes whether it is just by design in order to filter some reports and save them some work. I much appreciate your input, and I am sure that developers and product managers also value it.
 
Response from developers:

"I've found that the problem is related to the /etc/httpd/conf.d/welcome.conf configuration file which is used in RHEL/CentOS systems to display a standard welcome page in specific scenarios, such as when the index.html page is missing. Intestengly there is no such configuration on Ubuntu.
To resolve this issue, I recommend that the customer remove the configuration file using the following command:

Code:
mv /etc/httpd/conf.d/welcome.conf{,.back}
systemctl reload httpd

In addition, I suggest using the "Custom error documents" feature to configure custom error pages. This feature can be enabled in "Websites and Domains" -> [my.domain] -> "Hosting Settings" -> "Custom error documents".

Also, I've checked the "Custom error pages" feature is broken in these scenarios and have found that they are also affected. So I will create a bug to address this issue. Furthermore, I believe that the standard Apache page is not necessary on RHEL systems on Plesk systems."
 
Thank you for reporting back on this issue. I wasn't aware this was a OS specific issue, which is good to know.

[...] In addition, I suggest using the "Custom error documents" feature to configure custom error pages. This feature can be enabled in "Websites and Domains" -> [my.domain] -> "Hosting Settings" -> "Custom error documents".
Just to clear up any confusion I do want to point out that enabling custom error documents, as suggested by the developer, doesn't solve the issue. The default custom (Plesk) error document isn't shown either in this scenario.
 
Back
Top