https://issues.apache.org/bugzilla/show_bug.cgi?id=12428
--- Comment #26 from Werner Donn <werner.do...@re.be> 2010-12-17 04:05:00 EST --- There are two issues here. The first is pre-emptive authentication. RFC 2617 section 1.2 is very clear on this: " A user agent that wishes to authenticate itself with an origin server--usually, but not necessarily, after receiving a 401 (Unauthorized)--MAY do so by including an Authorization header field with the request." And further: "If the origin server does not wish to accept the credentials sent with a request, it SHOULD return a 401 (Unauthorized) response. The response MUST include a WWW-Authenticate header field containing at least one (possibly new) challenge applicable to the requested resource." This means the origin server must always deal with this, no matter the technology being used. The fact that a method is not declared as being protected doesn't play any role. The second issue is that according to you the application should not be able to trigger the challenge-reponse mechanism by setting the status code to 401. Can you give one piece of evidence in the servlet spec for this? Are there restrictions in the HttpServletRequest.setStatus() method that say the application can't use certain status codes? Here is what the servlet spec says about programmatic security: "Programmatic security is used by security aware applications when declarative security alone is not sufficient to express the security model of the application." Declarative security is fine, but doesn't prohibit programmatic security and programmatic security doesn't require declarative security to be present. They are simply not related. According to you they are. Can you tell me why? The patch shows how trivial it is to implement this correctly. Would harm be done if it were implemented? Which spec would be violated in that case? Your stance makes it impossible to implement WebDAV ACLs (RFC 3744). A user can change access control for a resource from protected to public. The former requires authentication prior to access control, while the latter doesn't. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
