Bug 48576

Summary: MOVE or COPY in WebDAV fails with 404 when file extension is changed
Product: Apache httpd-2 Reporter: presslab
Component: mod_davAssignee: Apache HTTPD Bugs Mailing List <bugs>
Status: REOPENED ---    
Severity: normal Keywords: MassUpdate
Priority: P2    
Version: 2.4.12   
Target Milestone: ---   
Hardware: PC   
OS: Linux   

Description presslab 2010-01-19 13:45:38 UTC
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
Comment 1 Stefan Fritsch 2010-01-29 15:13:57 UTC
Is something logged in the error log?

Make sure you have disabled MultiViews for the /webdav directory.
Comment 2 presslab 2010-01-31 09:24:51 UTC
(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.


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.


It still seems like a bug, yes?

Thanks for your help!
Comment 3 Wim Lewis 2011-05-02 18:50:14 UTC
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.
Comment 4 Wim Lewis 2015-03-11 02:26:09 UTC
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.
Comment 5 William A. Rowe Jr. 2018-11-07 21:08:01 UTC
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.
Comment 6 Christophe JAILLET 2018-11-09 20:17:39 UTC
Re-opening + update version.
Comment 4 states that it can be reproduced in 2.4.12.