Hi Philipp,
Here are my thoughts on the handling of 4xx series errors.
Here are my thoughts on the handling of 4xx series errors.
CASE A: If a user tries to access a page with an invalid URL
The user should get a 404 Not Found error regardless of whether the .php file exists or if it is because of something like an invalid course ID in the URL's parameters.
It does not matter because, in the end, there is no valid page to be displayed using the URL as a whole.
One could argue that a correct response might be a 400 Bad Request error, however, this is giving a potential hacker a hint as to the source of the problem which is undesirable.
Therefore I still think a 404 Not Found error is best in these cases.
CASE B: If the URL is valid but the user is not logged in
The user should be redirected to the login page.
If the user cannot access the page because they are not logged in, why would you send them anywhere else? This is simply the next logical step in the process of getting them to where they want to go.
Ideally, the login page would not only offer them to option to login, but also include an explanation as to why they ended up on this page unexpectedly.
If the login page page is unable to display a message indicating the reason why the user was redirected, a status page may need to be inserted in between. However, from an accessibility point of view, this is an extra page of content for someone to read and an extra click is then required - i.e. extra unnecessary steps.
It would therefore be better for all users if the login page had the ability to display a message explaining why the user ended up there unexpectedly.
Clients tell me all the time that Moodle requires too many clicks to get things done so this would help there too.
CASE C: If the URL is valid but the user fails to log in
The user should be redirected to a 401 Unauthorized error page.
This page should offer them a button which would take them back to the login page to try again.
You just want a standard message here, no explanation as to why they failed to login. You do not want to provide potential hackers with the reason why the attempted login failed.
CASE D: If the URL is valid and the user is logged in but they do not have access to the content
The user should be redirected to a 403 Forbidden error page.
This page should offer them a button to go back to the referred page. Sending people back to the home page or something like that when an error is encountered can be very disorienting and should be considered an accessibility issue.
Hope you find this helpful.
Best regards,
Michael Milette