WebDAV create write type is overwriting existing file

According to the documentation when using “create” write type to save a file to a WebDAV service, it should never overwrite an existing file.

Create a new file. If an existing file already exists at the location, create as new file with a number suffix added.

I’m having an issue where if I have an existing file titled text.md and I run a “create” action it is overwriting the original file when it should be saving as something like text-2.md

Is anybody else able to recreate this issue with WebDAV or is this possibly an issue with my WebDAV service (Nextcloud). I have no problem appending to existing files, so I’d be surprised if Drafts if unable to see the existing file.

Any nudge on how I can troubleshoot if this is an application bug vs maybe an issue with my actual WebDAV service would be greatly appreciated!

Played with this a little, and it does seem to be a bug. It should not create a -2 file or anything like that - but it should error out if the file exists. I’ll have to digging on it.

This turns out to be a bit complex.

You are correct that there is a bug, but I’ve also found that fixing the bug does not entirely solve the problem, because WebDAV implementation differ on how they implement handling of PUT requests…so, even after the bug is “fixed” the outcome may be different by WebDAV implementation. Honestly, I’m not entirely clear on how to interpret parts of the WebDAV spec. Maybe I’m not the only one, since implementations are not all behaving the same.

As it stands, the Drafts is not including the “Overwrite: T/F” header as it should. I’ve fixed that, but in the two WebDAV implementations I test against:

  • Box.com’s WebDAV takes the request update the file, and if “Overwrite: T” is included, it updates the files - this should be the “Replace” behavior. If “Overwrite: F” is included, it does not update the file - though it returns a 203 HTTP success code that would indicate the request was successful. :man_shrugging:t2:
  • Synology’s WebDAV implementation just ignores the “Overwrite” header, and regardless of whether it is T or F it replaces the content of the file.

I may just have to deal with this in the docs and explain handling may vary between WebDAV servers.


Thank you for digging in to this! I know this is an action that a very small number of users actually use… but I being one of them appreciate the effort.

Once the overwrite header is implemented I will test against the NextCloud WebDAV implementation. If it isn’t working correctly I’ll open an issue on the Nextcloud project so they can take a look.

1 Like