- From: <bugzilla@soe.ucsc.edu>
- Date: Wed, 15 Feb 2006 14:09:22 -0800
- To: w3c-dist-auth@w3.org
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 UTC