> I'm trying to disable HTTP PUT on my Glassfish v2.1 AS. The network security scanner tool I'm using detects that HTTP PUT is enabled and flags it as vulnerability. We don't need to use PUT, so I liked to lock down the configuration and clear the vulnerability. I've done some research and testing and here is what I found.
>
> With the above knowledge I wanted to test whether I could disable HTTP PUT. My test is a simple java.net.HttpURLConnection that I set the request method to "OPTIONS" and then I print out the header information of the response (source below). When I test against my web application the "Allow" header property does not include PUT or DELETE, but if I test against a static resource (like the URL in the source code), then all the HTTP methods are allowed. I want an HTTP OPTIONS request to not return PUT. Any ideas?
>
This is due to how the HttpServlet works. This servlet implements the
doOptions method which returns the list you see.
It looks recursively into all methods of the complete class hierarchy of
the servlet responsible for the path you entered up to HttpServlet
itself. Any methods declared in any servlet except HttpServlet itself
are then checked for doXyz methods to determine the http methods supported.
The DefaultServlet has a doPut() method (which takes care of the
readOnly configuration), thus PUT is returned in the list.
> (...)
>
> Also, I am going to further investigate the default servlet, which is an instance of org.apache.catalina.servlets.DefaultServlet. It must be handling my requests to static resources, and the jsp servlet to my web application's servlet (or default is forwarding to jsp, does someone know?), even though the URL pattern is "*.jspx". My suspicion here is because I configured jsp to only allow certain HTTP methods and I only saw those methods advertised when I hit my servlet's URL.
>
Yes, the DefaultServlet is for handling static resources and the
JspServlet for JSPs. The JspServlet has servlet-mappings for *.jsp and
*.jspx.
--
Wolfram Rittmeyer