WebDAV Sync Fails with E019: HTTP 404 on PUT Request, Strangely Resolved by an Unrelated WebDAV Operation

[MCQSJ]

Which version of floccus are you using?

5.6.0

How many bookmarks do you have, roughly?

Approximately 200

Are you using other means to sync bookmarks in parallel to floccus?

No

Sync method

WebDAV

Which browser are you using? In case you are using the phone App, specify the Android or iOS version and device please.

Microsoft Edge (140.0.3485.94) Mozilla Firefox (144.0) (Both on the same Windows PC)

Which version of Nextcloud Bookmarks are you using? (if relevant)

No response

Which version of Nextcloud? (if relevant)

No response

What kind of WebDAV server are you using? (if relevant)

I am using the WebDAV service provided by a Chinese cloud storage provider called "123pan" (webdav.123pan.cn).

Describe the Bug

I have floccus installed on both Edge and Firefox on the same computer, configured to sync with the same WebDAV account from 123pan.cn. Initially, syncing works correctly on both browsers. However, after some period of time, both browsers simultaneously start failing to sync.

The error message is: Syncing failed with E019: HTTP status 404. Failed PUT request. Check your server configuration and log.

Here is a relevant snippet from the error log:
2025-10-18T02:40:07.038Z Starting sync process for account dav-sys
2025-10-18T02:40:07.039Z onSyncStart: begin
2025-10-18T02:40:07.040Z https://webdav.123pan.cn/webdav/bookmarks.xbel.lock
2025-10-18T02:40:07.330Z Setting lock: https://webdav.123pan.cn/webdav/bookmarks.xbel.lock
2025-10-18T02:40:07.721Z Syncing failed with E019: HTTP status 404. Failed PUT request. Check your server configuration and log.
2025-10-18T02:40:07.722Z onSyncFail

The most peculiar part is the temporary fix. I also have the Tampermonkey extension installed, which has a script that can perform WebDAV backups. If I use this Tampermonkey script to perform a backup to the same WebDAV server (webdav.123pan.cn), but using a different account and password (which points to a different directory), the floccus sync immediately starts working again on both browsers without any changes to the floccus configuration.

floccus-5.6.0-2025-10-18-full.log

Expected Behavior

I expect the WebDAV sync to work consistently without failing with a 404 error. I should not need to perform an unrelated WebDAV action with another tool to temporarily fix the sync functionality.

To Reproduce

Set up floccus on two different browsers (e.g., Edge and Firefox) on the same machine.
Configure both to sync with the same WebDAV account provided by webdav.123pan.cn.
Perform a successful sync on both.
Wait for an indeterminate period (from a few hours to a day).
Attempt to sync again and observe the E019: HTTP status 404 error on both browsers.
Workaround Verification: Use a separate tool or script (like a Tampermonkey script) to access the same WebDAV server host (webdav.123pan.cn), even with a different account.
Immediately try syncing with floccus again. Observe that the sync now succeeds.

Debug log provided

• I have provided a debug log file

[github-actions]

Hello! 👋

Thank you for taking the time to open this issue with floccus. I know it's frustrating when software causes problems. You have made the right choice to come here and open an issue to make sure your problem gets looked at and if possible solved. Let me give you a short introduction on what to expect from this issue tracker to avoid misunderstandings. I'm Marcel. I created floccus a few years ago, and have been maintaining it since. I currently work for Nextcloud which leaves me with less time for side projects like this one than I used to have. I still try to answer all issues and if possible fix all bugs here, but it sometimes takes a while until I get to it. Until then, please be patient. It helps when you stick around to answer follow up questions I may have, as very few bugs can be fixed directly from the first bug report, without any interaction. If information is missing in your bug report and the issue cannot be solved without it, I will have to close the issue after a while. Note also that GitHub in general is a place where people meet to make software better together. Nobody here is under any obligation to help you, solve your problems or deliver on any expectations or demands you may have, but if enough people come together we can collaborate to make this software better. For everyone. Thus, if you can, you could also have a look at other issues to see whether you can help other people with your knowledge and experience. If you have coding experience it would also be awesome if you could step up to dive into the code and try to fix the odd bug yourself. Everyone will be thankful for extra helping hands! If you cannot lend a helping hand, to continue the development and maintenance of this project in a sustainable way, I ask that you donate to the project when opening an issue (or at least once your issue is solved), if you're not a donor already. You can find donation options at https://floccus.org/donate/. Thank you!

One last word: If you feel, at any point, like you need to vent, this is not the place for it; you can go to the Nextcloud forum, to twitter or somewhere else. But this is a technical issue tracker, so please make sure to focus on the tech and keep your opinions to yourself.

Thank you for reading through this primer. I look forward to working with you on this issue! Cheers! 💙

[marcelklehr]

Hi @MCQSJ
Thank you for taking the time to give feedback by opening this issue. This sounds a lot like an issue with your cloud provider, rather than an issue with floccus 🤔

[MCQSJ]

Hi   你好@MCQSJ Thank you for taking the time to give feedback by opening this issue. This sounds a lot like an issue with your cloud provider, rather than an issue with floccus 🤔感谢您抽出宝贵时间通过打开此问题来提供反馈。这听起来更像是与您的云服务商相关的问题，而非 floccus 本身的问题 🤔

Thank you for your response! I understand your point that this might be related to the cloud provider. However, I’d like to clarify that other WebDAV clients—including Tampermonkey scripts, third-party backup tools, and even manual curl requests—work consistently without any 404 errors on the same WebDAV endpoint (webdav.123pan.cn), even during the exact time window when Floccus fails with E019.

The truly puzzling behavior is that performing any unrelated WebDAV operation (e.g., uploading a file to a different account/directory on the same host via another tool) immediately restores Floccus sync functionality on both browsers—without restarting the browser, clearing cache, or changing Floccus settings.

This strongly suggests that the issue may involve how Floccus handles connection state, authentication caching, or lock file management with certain WebDAV servers—especially those that might enforce session-like behavior or connection reuse policies not fully compliant with standard WebDAV expectations.

Since the workaround consistently works and the problem is reproducible across two browsers simultaneously, I suspect there might be an edge case in Floccus’s WebDAV interaction logic that triggers a stale or invalid state, which gets “reset” by an external WebDAV request.

I’d greatly appreciate it if the team could look into this further—perhaps by examining the lock file handling or HTTP client behavior in Floccus 5.6.0 when interacting with non-standard WebDAV implementations.

Thanks again for your time and for maintaining such a great tool!