Subject: [Bug 144] IF_HEADER_CHECKS_AFTER_OTHER_CHECKS

From: [email-masked]
Date: Wed, 15 Feb 2006 14:09:22 -0800

http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=144

[email-masked] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
           Priority|P2                          |P3
         Resolution|FIXED                       |
            Version|-12                         |-13

------- Additional Comments From [email-masked]  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.