Bug 54875 - Conditional request predicated on another URL's ETag always succeeds, even when it shouldn't
Summary: Conditional request predicated on another URL's ETag always succeeds, even wh...
Status: NEW
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_dav (show other bugs)
Version: 2.5-HEAD
Hardware: All All
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Keywords: RFC
Depends on:
Reported: 2013-04-23 00:24 UTC by Wim Lewis
Modified: 2016-03-14 20:28 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Wim Lewis 2013-04-23 00:24:38 UTC
Making a MOVE or COPY request with an If: header predicated on another resource's ETag always succeeds, regardless of whether the ETag matches or not.

To reproduce:

PUT a file into a collection somewhere (e.g. /collxn/FileA), and retrieve its etag using PROPFIND.
PUT another file into that collection (e.g. /collxn/FileB).
Attempt to MOVE or COPY FileB to FileC, supplying an If: header that references FileA.

There are two cases in which the MOVE/COPY should fail, and in both cases it succeeds instead:

Case 1:
   If: </collxn/FileA> (Not ["blah-blah-etag"])
where "blah-blah-etag" is FileA's current ETag

Case 2:
   If: </collxn/FileA> (["wrong-etag"])
where "wrong-etag" is not FileA's current ETag (e.g. because FileA has been replaced by an intervening PUT).

Tested against trunk/2.5 r1470683 and against 2.4.4; Apache has the same behavior on both branches.
Comment 1 Wim Lewis 2016-03-14 20:28:17 UTC
FWIW, it seems like Apache's behavior may be correct according to RFC2518 (section 9.4.2, paragraph 2), although that RFC is fairly ambiguous about the intended semantics of the If: header. RFC4918, however, does not include that text from RFC2518, which makes me think that Apache's behavior is incorrect according to the current WebDAV spec.