W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2006


From: <bugzilla@soe.ucsc.edu>
Date: Wed, 15 Feb 2006 14:09:22 -0800
Message-Id: <200602152209.k1FM9M7r001800@ietf.cse.ucsc.edu>
To: w3c-dist-auth@w3.org


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

- 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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:35 UTC