Feature Request/Idea: catch-all error pages

[eunices]

Overview of the Feature Request
Create a catch-all error page

What kind of user is the feature intended for?
All

What inspired the request?
Error pages reveal Payara version. It doesn’t provide user with support email to ask for help.

The curl command has response 405 and reveals Payara version error pages:
curl -X PUT https://$SERVER_URL

The curl command has response 501 and reveals Payara version error pages:
curl -X UNLOCK https://$SERVER_URL

What existing behavior do you want changed?
None

Any brand new behavior do you want to add to Dataverse?

• Create a generic, catch-all custom error page, that is similar to 404.xhtml

“Oops, something went wrong!” place of “ Page Not Found - The page you are looking for was not found.” (red bounding box in screenshot below)
“If you believe this is an error, please contact {0} for assistance.” should remain.

Under web.xml add:

<error-page>
   <location>/error.xhtml</location>
</error-page>

See reference: https://stackoverflow.com/questions/2237434/multiple-error-code-configuration-web-xml

[pdurbin]

Overall, I like this idea. I just thought I'd note that if I try

curl -X FOOBAR http://localhost:8080 (my dev laptop), I do get the Payara version, as explained above.

However, if I try

curl -X FOOBAR https://demo.dataverse.org I get the Apache version, which seems less bad to me. (Apache is easily upgraded with a package manager, typically.)

[eunices]

Just a quick input.

The result of curl -X FOOBAR https://<server> depends on the config of each installation's Apache. It may be better to standardize at the application level.

[eunices]

@pdurbin I'm sorry - I accidentally closed the issue and it got pushed to "Done" via automation. Kindly change back to "Up Next" where it was.

[landreev]

I tried adding an error page without the code specified, as described above, and I'm seeing some strange behavior. It is working for the first example - sending PUT to the top page; which results in a 405 "PUT is not supported". However, this catch-all solution does not in fact appear to be catching ALL errors. The next example, an attempt to use an illegal method ("-X FOOBAR") results in empty output (i.e., no error page or output of any kind - neither the Payara, nor the custom page I put in place), and the code 400, instead of 501 that was observed previously. (??) There is nothing in the server log. I can't immediately think of an explanation for this.

[landreev]

I'm beginning to question whether this is necessary. Or at least whether we want this error page to be modeled after our 404.xhtml; i.e. does it need to be a rich HTML page? After all, neither of the examples above would ever be sent from a user's browser in real life. So it should probably be plain text or basic json for exotic HTTP codes like that (?).

[pdurbin]

My 2 cents... whatever's easiest to implement! 😄

[landreev]

@eunices Hi, do you have any thoughts about the behavior I saw when I tried adding this "universal error page" to web.xml, described above? - that somehow changes the HTTP code returned in response to "-X FOOBAR", from 501 to 400; and no longer produces ANY output:

% curl -X FOOBAR "http://localhost:8080" 
%
(empty response)

with headers:

% curl -i -X FOOBAR "http://localhost:8080"
HTTP/1.1 400 Bad Request
Server: Payara Server  5.2021.7 #badassfish
X-Powered-By: Servlet/4.0 JSP/2.3 (Payara Server  5.2021.7 #badassfish Java/AdoptOpenJDK/11)
Content-Type: application/xhtml+xml;charset=UTF-8
Connection: close
Transfer-Encoding: chunked
X-Frame-Options: SAMEORIGIN

%

Have you tried it yourself, is there a trick ... ? I'm out of ideas really and didn't immediately find an answer online. And the Payara error page seems like a better option than no page at all...
(creating dedicated entries specifically for 400 and 501, in addition to this "catch-all" page doesn't help either)

[landreev]

@eunices What is the use case for having a "pretty" html page for these, more exotic HTTP error codes anyway? I'm not dismissing it outright, just trying to understand. We maintain the custom pages for the 403, 404 and 500 codes because web users actually get these errors when using the site. With the codes like the "501 - method not defined" in the example above - would a regular user ever get that error in a browser? (I may be missing something of course).
(A simple alternative approach may be to try and put together one generic error page, but then maintain separate <error-page> sections in web.xml for the codes that are likely to be produced by Dataverse; all referencing the same generic page - ?).

[eunices]

Hi @landreev apologies for the slow reply. I'm not too familiar with the Github notifications and missed this one.

@eunices Hi, do you have any thoughts about the behavior I saw when I tried adding this "universal error page" to web.xml, described above? - that somehow changes the HTTP code returned in response to "-X FOOBAR", from 501 to 400

I did not tried these scenarios, it's strange that with and without headers the responses are different with the universal error page. It could be a bug.

(A simple alternative approach may be to try and put together one generic error page, but then maintain separate <error-page> sections in web.xml for the codes that are likely to be produced by Dataverse; all referencing the same generic page - ?).

I see, that could be fine as well, redirecting to a generic page for 501 and and 405, instead of a catch-all which seems to be buggy.

[landreev]

I took another shot at this. I checked in an example of adding this "generic page", not as a catch-all, but specifically for the code 405 (one of the 2 initial examples). (see the tagged branch) The approach does not work for the code 501 (you just cannot define a custom error-page for 501 - I have no idea why). I have not tried to find out which other return codes it works or does not work for.
As I said earlier, I'm not sure this is actually worth the effort. Especially since in real life error codes other than 403/404/500 are rarely seen by human users, then maybe the simple pages Glassfish or Apache are showing for these codes are actually preferable - ?

Considering moving this into community-dev for somebody else to take a whack at it.

[eunices]

Thanks @landreev for the update.
Yes, if a catch-all error page is buggy then it might not be worth the effort. Thanks for following up and testing.