问题
I'm using a web.xml to try and disable the HTTP methods we're not using and to return a body that doesn't contain any tomcat info.
So I've changed the web.xml of the app to have:
<security-constraint>
<web-resource-collection>
<web-resource-name>restricted methods</web-resource-name>
<url-pattern>/*</url-pattern>
<http-method>TRACE</http-method>
<http-method>PUT</http-method>
<http-method>OPTIONS</http-method>
<http-method>DELETE</http-method>
<http-method>HEAD</http-method>
</web-resource-collection>
<auth-constraint />
</security-constraint>
So the blocked methods are returning 403 with an empty body, for forbidden. But TRACE is returning a 405 with a Tomcat HTML page.
I tried redirecting all errors through an ErrorServlet with:
<error-page>
<location>/ErrorServlet</location>
</error-page>
Which just makes sure that the content body is 0. But that doesn't seem to intercept these.
So why is TRACE being treated differently?
Thanks
回答1:
It makes perfect sense to me, because in all cases except TRACE you're submitting a requests for a web resource identified by a URL and code 403 means that an access to the resource is denied. Try to get access to the same resource using allowed methods. Probably it's forbidden for them as well?
TRACE on the other hand doesn't require an access to any resource, it simply echoes the client's input, so 405 ("METHOD NOT ALLOWED") looks appropriate for this case.
It's a good idea to have custom error pages. Examples specific for each error code can be found here: https://serverfault.com/questions/254102/custom-error-pages-on-apache-tomcat
来源:https://stackoverflow.com/questions/25062176/tomcat-security-constraints-trace-inconsistent