[Bug 60697] TRACE method incorrectly advertised as a supported HTTP method for custom servlet

[bu...@apache.org]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60697

--- Comment #1 from Mark Thomas <ma...@apache.org> ---
This has been looked at before which is why the DefaultServlet handles this
correctly. Requests for "OPTIONS *" are also handled correctly.

It is difficult to do this for custom servlets since the code that handles the
OPTIONS request is in javax.servlet.http.HttpServlet. This is a specification
class so we can't change the API and neither can it depend on any Tomcat
specific classes.

That leaves us with two options. Use reflection in HttpServlet or filter  TRACE
from the Allow header when it is disabled.

I don't really like either option. Using reflection in HttpServlet is a fairly
ugly hack and filtering the headers is going to add overhead to every request.
Of the two, reflection is the least bad option.

A third option is never including TRACE in Allow headers generated by
HttpServlet. The problem with that is that it may well break applications that
depend on it and it would result in a non-specification compliant response when
TRACE was allowed.

I have a test case for this that I'll commit shortly. That test case identified
a scenario when the WebDAV servlet included TRACE in the response when it was
disabled. That is an easy fix.

I'll take a look at what the reflection code looks like for HttpServlet. If it
isn't too ugly I'll go that route.

A completely different option is to always include TRACE in the OPTIONS
response but respond with a 403 rather than a 405 which is, arguably, more
specification compliant behaviour - although the security scanners might not
like it.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org