Thank you, I was away for a few days myself. I agree with you that it would be unwise to change the DefaultServlet, in light of the fact that so many use it. Having looked into the issue and now understanding it more completely, I have the knowledge to rule it as a false positive. Although one possibility remains and I would appreciate your opinion, and that possibility is using a filter on the DefaultServlet to handle OPTIONS and PUT requests. By handling those request before the DefaultServlet I can tailor the OPTIONS response to what will be handled, and I can block PUT requests outright. Is this feasible or reasonable?
The scanner tool I used was eEye's Retina Network Security Scanner. The vulnerability was exposed only when I used the custom audits provided by our customer, which I can not provide.
I also agree that doOptions could better reflect what the protocol isn't currently responding to, but perhaps it was felt that an "HTTP 403: Forbidden" response was more expressive of the permitted protocol methods.
Thanks again for your responses.
[Message sent by forum member 'martin_woolstenhulme' (martin_woolstenhulme)]
http://forums.java.net/jive/thread.jspa?messageID=339672