In Servlet Security Constraint configuration, HTTP methods may be left uncovered in the following
1. a security constraint names one or more HTTP methods in http-method elements.
All methods other than those named in the constraint are uncovered.
2. a security constraint names one or more HTTP methods in http-method-omission elements.
All methods that are named in the constraint are uncovered.
3. a @ServletSecurity annotation includes one or more HttpMethodConstraint objects,
each naming an HTTP method, and the top level HTTPConstraint that applies to all other
methods is indistinct from the default value which defines no protection requirements.
This case is analogous to case 1, and all methods other than those named in the
HTTPMethodConstraint objects are uncovered by the annotation.
fwiw, The setServletSecurity api can be used to achieve an analogous effect.
Servlet has proposed the definition of an optional flag in web.xml that when set for an app,
will cause, following constraint combination, any remaining uncovered methods (resulting from
any of the above causes), to be configured as denied. This conversion is consistent with the
recommendation that all methods be covered in constraint definition.
For JACC the issue is to enhance the Policy Configuration contract to perform the processing necessary to support the new Servlet flag