On 30/01/2013 20:19, Bill Shannon wrote:
> I'm sure you're aware that security issues in the Java platform are
> receiving additional attention lately. While addressing this issue
> is only one small step, we and others feel it is an important one.
> Unless a technical flaw is discovered in the proposed approach, we
> intend to include this in Servlet 3.1.
A number of issues have been highlighted with this proposed change.
1. What happens when security constraints are included for a fragment
with one value for this new setting and the security constraints for the
main web.xml are written for the other value?
2. Complexity. Given the amount of time it took the Servlet EG to get
its head around this proposal and that the EG is meant to have a very
good grasp of the specification how realistic is it to expect that users
are going to understand a security model even more complex that the one
we have already?
3. A significant factor in justifying this change was verb tampering. As
already explained that is an issue with the JSP specification (with a
fix in hand) not the Servlet specification.
This proposal is aimed at addressing an increasingly limited issue that
the specification already has the features in place for users to address
and does so by making a complex feature already more complex. That does
not strike me as a sensible thing to do.
I'd support a change to the specification that required the container to
log potential issues along with a pointer to the section of the
specification that explains how to avoid them using the currently
available features.
Mark