Bug 54875

Summary: Conditional request predicated on another URL's ETag always succeeds, even when it shouldn't
Product: Apache httpd-2 Reporter: Wim Lewis <wiml>
Component: mod_davAssignee: Apache HTTPD Bugs Mailing List <bugs>
Status: NEW ---    
Severity: normal Keywords: RFC
Priority: P2    
Version: 2.5-HEAD   
Target Milestone: ---   
Hardware: All   
OS: All   

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.