Allow ServletContext level removal of TRACE from OPTIONS response Allow header

[joakime]

Currently, the only way to remove TRACE from the OPTIONS response Allow header is to override the doOptions method on every servlet you implement.
This isn't always feasible with 3rd party libraries and whatnot.

While there is a way to use Constraint mappings to disable TRACE (well, it actually returns "403 Not Authorized" instead of the more useful "405 Method Not Allowed") at the ServletContext level, there's no way to have that change also impact the OPTIONS Allow header at the same time.

[markt-asf]

I like this idea. Being able to control the default TRACE behaviour per ServletContext, whilst still allowing individual Servlets to override it would be a nice enhancement in 6.0. Now for the tricky part. What to call the new attribute? allowTraceByDefault that defaults to false?

[joakime]

Having a high level switch, perhaps in the descriptor, to manage HTTP method usage?

Using the Constraint mapping is just awkward and doesn't convey the proper behavior, as all you are doing is setting up an authentication requirement on a method and then having no realm for that method resulting in 100% rejection of that method.

Idea 1: Descriptor level HTTP method include/exclude controls.

Include / Exclude by HTTP method name? Each a list.
If Exclude has configuration it wins, and results in a 405 Method Not Allowed, and removal from OPTIONS / Allow header.
If Include has configuration and method requested isn't present, it results in a 405 Method Not Allowed, and OPTIONS / Allow header is the include list (no discovery like in current doOptions)

<!-- reject TRACE, always remove from OPTIONS/Allow, allow all others as normal -->
<http-methods>
  <exclude>TRACE</exclude>
</http-methods>

<!-- limited methods allowed, reject all others -->
<http-methods>
  <include>GET</include>
  <include>HEAD</include>
  <include>POST</include>
  <include>PUT</include>
</http-methods>

Idea 2: Descriptor level HTTP method behavior.

Allow specific methods to have hardcoded status and options-allow behavior.

<!-- reject method TRACE as default behavior, hide from OPTIONS/Allow as default behavior. -->
<http-method>
  <method>TRACE</method>
  <status>405</status>
  <options-allow>hide</options-allow>
</http-method>

<!-- default behavior is to return 404 for DELETE, default behavior is to always show DELETE in OPTIONS/Allow header. -->
<http-method>
  <method>DELETE</method>
  <status>404</status>
  <options-allow>always</options-allow>
</http-method>

[joakime]

This should probably also have ServletContext level methods to set/list/remove theses behaviors programmatically.

What I don't know is ...

Should this descriptor level configuration be a final decision like Constraint mapping where it overrides the application desires?

Or should this descriptor level configuration only modify the default behavior in the HttpServlet base class? Allowing applications to override the behavior by implementing the appropriate doTrace / do<Method> methods in their own Servlet?