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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
