-
-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve ErrorDocument config in .htaccess #33048
Comments
See nextcloud/server#33048 for more background. In a Nutshell: * The contacts app makes many requests to load contact images like `/remote.php/dav/addressbooks/users/<user>/<Addressbook>/<contact-uid>.vcf?photo=` * The `ProxyErrorOverride` config in Uberspace accounts hides the 404 error thrown by Nextcloud and opens the configured `ErrorDocument` from `.htaccess` * The default error document redirects the user to the Nextcloud start page (Dashboard) * This means a lot of requests are made at once to load the Nextcloud dashboard which can lead to a completely hung up Nextcloud instance until restarting the PHP service with `uberspace tools restart php`
Sounds like the best solution and we should provide a nice 404 page instead of just redirecting to the homepage, this is pretty standard behavior for websites and I'm always a bit annoyed when Nextcloud redirects me to the homepage instead of telling me that I wrote the wrong URL/ I don't have access to the resource What do you think @nextcloud/designers ? |
Agreed that redirecting to dashboard makes no sense if the entered URL is wrong :) |
I can confirm that my issue #33228 is another use case of this and from my understanding. Commenting out the two ErrorDocument lines fixes the problem. I think this is non-standard behaviour for the DAV module because nextcloud returns the wrong error code in my case. So, I leave my issue open for now, as it is clearly a bug. |
See nextcloud/server#33048 for more background. In a Nutshell: * The contacts app makes many requests to load contact images like `/remote.php/dav/addressbooks/users/<user>/<Addressbook>/<contact-uid>.vcf?photo=` * The `ProxyErrorOverride` config in Uberspace accounts hides the 404 error thrown by Nextcloud and opens the configured `ErrorDocument` from `.htaccess` * The default error document redirects the user to the Nextcloud start page (Dashboard) * This means a lot of requests are made at once to load the Nextcloud dashboard which can lead to a completely hung up Nextcloud instance until restarting the PHP service with `uberspace tools restart php`
This keeps happening every time I update nextcloud. Is it planned to fix this? |
Has been addressed in #34662 |
If this is really resolved, it shouldn’t happen when upgrading from nextcloud 26 to 27, right? Because that’s what I did when the error occured the last time. |
The current ErrorDocument configuration that is written to the .htaccess causes problems in some environments:
When the Apache Webserver is configured with
ProxyErrorOverride
the HTTP error handling for 403 and 404 errors is broken. Users no longer get the correct error codes and error messages. Instead they are redirected to the dashboard.When you are running Nextcloud on your own server the solution is simple: do not use
ProxyErrorOverride On
. But there are also hosters that use this setting and provide no possibility to disable it.In most cases this is probably only a minor issue / nitpick but there is (at least) one concrete case where this leads to real problems: the contact images. The contacts apps makes a request for each contact visible in the list:
When the user is now redirected to the dashboard for each requests where no image is found instead of just getting a 404 error the server can get overloaded.
Possible solutions
Here are some suggestions to solve the issue:
Remove ErrorDocument directives
I'm not sure what the rationale behind the current
ErrorDocument
directives is. From my point of view they could just be removed without loosing anything.Add config options to customize ErrorDocument directives
If removing the the directives is not possible, allowing the configuration of custom error documents would be a good alternative, e.g in:
Bring back error actions
There are templates left over at
/core/templates/403.php
and/core/templates/404.php
. These templates could be made available again in controller actions that output the correct HTTP-Headers. Those actions could the be uses in the .htaccess file, e.g.I would be happy to help out with a pull request.
The text was updated successfully, but these errors were encountered: