Am 2020-04-20 um 15:11 schrieb Konstantin Kolinko:
пн, 20 апр. 2020 г. в 11:05, Mark Thomas <ma...@apache.org>:
On 18/04/2020 20:59, micha...@apache.org wrote:
This is an automated email from the ASF dual-hosted git repository.
michaelo pushed a commit to branch 7.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/7.0.x by this push:
new 08879ae Remove redundant sole path/URI from error page message on
SC_NOT_FOUND
08879ae is described below
commit 08879aeb5e30933bc0a6aaea6c1fa8a9ef4b8a58
Author: Michael Osipov <micha...@apache.org>
AuthorDate: Sat Apr 18 20:58:40 2020 +0200
Remove redundant sole path/URI from error page message on SC_NOT_FOUND
When a component issues a SC_NOT_FOUND don't respond with the path/URI
only in
the error message because it does not offer any more detail about the
error,
plus the client knows the path/URI already.
Not necessarily. The client has no visibility of forwards or includes.
In a more complex application it might not be obvious that a forward /
include has occurred. Including the path for the resource that could not
be found makes debugging significantly easier.
I think this change should be reverted.
I am -1 on this change. I agree that it should be reverted.
I have seen this message from DefaultServlet many times and it is rather useful.
If a programmer wants to hide the error path, the widely used practice
is to configure a custom error page for the error code 404.
I cannot comment on other servlets (WebdavServlet, SSIServlet,
JSPServlet) touched by this commit.
this will also apply to JSP servlet when you ask the request dispatcher
to forward to a JSP page.
I will work on decent messages for DefaultServlet and JSPServlet
tomorrow. The WebDavServlet makes no real sense because the responses
are for automated clients. They will happily ignore the HTML error page.
M
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
