http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=144 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Priority|P2 |P3 Resolution|FIXED | Version|-12 |-13 ------- Additional Comments From julian.reschke@greenbytes.de 2006-02-15 14:09 ------- While resolving the issues raised during the 2006-02-15 telecon, I also tried to come up with language that would explain when to return a 412 or not, and failed (thus reopening this one for discussion). As far as I can tell, the only requirements that actually make sense and can be specified in a same manner are: - Conditional header checks must not cause information to leak out that may be sensitive, such as whether a particular resource exists. We already say that in <http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-13.html#error-precedence>. - Consequently, authentication must have happened before that. Now, if an If header has a Condition on a resource (other the one identified by the Request-URI) the authenticated principal is not allowed to see, do we require a 403 (check before If), a 412 (let If fail), or something else? It's not clear to me whether we can mandate anything here. In particular, a server that hides resources for which the principal doesn't have access to probably wouldn't want to fail the reqeust with 403, but with a 412 (treating access problems the same way as resource not found). Feedback appreciated; in the meantime I leave the If header definition as it used to be (requiring a 412 when it evals to false). ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.Received on Wednesday, 15 February 2006 22:09:29 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 12 October 2007 17:53:26 GMT