For example move keepass.kdbx.tmp2 to keepass.kdbx fails with 404, but moving keepass.kdbx.tmp to keepass.kdbx.tmp2 works fine. This breaks the KeePass program as it uses move in this fashion. From cadaver: dav:/webdav/> mv keepass.kdbx keepass.kdbx.tmp Moving `/webdav/keepass.kdbx' to `/webdav/keepass.kdbx.tmp': succeeded. dav:/webdav/> mv keepass.kdbx.tmp keepass.kdbx.tmp2 Moving `/webdav/keepass.kdbx.tmp' to `/webdav/keepass.kdbx.tmp2': succeeded. dav:/webdav/> mv keepass.kdbx.tmp2 keepass.kdbx Moving `/webdav/keepass.kdbx.tmp2' to `/webdav/keepass.kdbx': failed: 404 Not Found dav:/webdav/> ls Listing collection `/webdav/': succeeded. KeePass.zip 6164267 Dec 26 16:25 keepass.kdbx.tmp2 38206 Jan 18 16:50 dav:/webdav/>
Is something logged in the error log? Make sure you have disabled MultiViews for the /webdav directory.
(In reply to comment #1) > Is something logged in the error log? > Make sure you have disabled MultiViews for the /webdav directory. There was nothing in the error log when I received that 404 reply. I have disabled MultiViews and it solved the problem! Apparantly KeePass changed the way it saves in version 2.09. http://kerkhove.net/glob/1/2009-11-29/hello-world.html/comment-page-1 I read about MultiViews and it doesn't seem like it should break anything that KeePass does. It should only look for other files if the requested one does not exist. http://httpd.apache.org/docs/2.0/mod/mod_negotiation.html It still seems like a bug, yes? Thanks for your help!
I agree that this seems like a bug. The WebDAV WG decided not to try to figure out the right interaction between DAV and content negotiation, so it's probably best to just disable MultiViews on a DAV directory, but Apache's current behavior seems unambiguously wrong. The general case that causes this problem for me is MOVEing a collection to a destination URL which is only mapped as a result of content-negotiation. For example, if I have file Foo.txt and collection Bar, then moving Bar to Foo will fail with 404. IMHO Apache should do one of: 1: Fail with 412 if Overwrite: F was sent; succeed if Overwrite: T was sent. 2: Succeed whether or not Overwrite: T was sent (on the theory that you're not overwriting anything) 3: Fail with another 4xx error code such as 409 Conflict. I think #1 is probably most correct. #2 is probably closest to what most clients want, but I don't think it is truly correct from a webdav point of view: The Foo resource does actually exist, even though "overwriting" it does not result in the loss of any data. #3 would be a compromise to keep Apache's current behavior but return a more accurate error code.
This bug/behavior seems to still exist in 2.4.12, even with various settings of MultiviewsMatch. For example, in a directory in which thing2.txt.en exists, and with mod_negotiation and mod_mime applied: dav:/> cat thing2.txt.en Displaying `/thing2.txt.en': The contents of a thing. Random number: 917 dav:/> cat thing2.txt Displaying `/thing2.txt': Failed: 404 Not Found dav:/> cat thing2 Displaying `/thing2': Failed: 404 Not Found dav:/> mv thing2.txt.en thing2 Moving `/thing2.txt.en' to `/thing2': failed: 404 Not Found dav:/> mv thing2.txt.en thing2.txt Moving `/thing2.txt.en' to `/thing2.txt': failed: 404 Not Found But, with MultiViews disabled: dav:/> mv thing2.txt.en thing2.txt Moving `/thing2.txt.en' to `/thing2.txt': succeeded. dav:/> mv thing2.txt thing2 Moving `/thing2.txt' to `/thing2': succeeded.
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd. As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd. If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question. If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with. Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.
Re-opening + update version. Comment 4 states that it can be reproduced in 2.4.12.