[GH-ISSUE #956] WebDAV Sync problems

kerem commented

2026-02-25 22:37:39 +03:00

Owner

Originally created by @DerDanilo on GitHub (Sep 13, 2021).
Original GitHub issue: https://github.com/floccusaddon/floccus/issues/956

Describe the bug

Sometimes the webdav sync seems to be broken. On some occasions floccus reported that everything was fine and synced, when in fact, nothing was fine. Trying a manual sync didn't solve the issues either.
Restarting the browser, checking network connections etc. didn't solve the issue either.

To Reproduce

Steps to reproduce the behavior:

Setup floccus sync with webdav backend
Start using it
Wait for the error (not syncing bookmarks, while telling everything is fine) to appear randomly
OR: Wait for all bookmarks are messed up because of IDK; sync issues with a webdav backend?!
Freak out because all bookmarks are messed up
Remember that you have file versioning enabled, restore old version of bookmark sync, reset bookmarks, start syncing from zero

Expected behavior

Floccus should detect if there is a sync error and report it. This seems either a sync issue or the algo doesn't properly detect if there is a sync error.

Desktop

OS: Linux, Windows, Mac (all the same)
Browser chrome and firefox
Browser Version: various
Floccus version: 4.7; but the problem existis since I started using floccus last year.
Floccus sync method: webdav, nextcloud bookmark app couldn't handle the amount of bookmarks

Server

(please complete the following information)

OS: Debian 10
Nextcloud version: [if applicable]
Seafile CE WebDAV : 7 and 8; but this should not be relevant I think since it works with other Seafile servers running the same versions and config
Bookmarks app version: [if applicable]

Note: Please write down the actual version numbers instead of writing 'latest'.

Debug log

Sometimes the following error appears once one starts trying to force a sync (dangerous actions)

2021-09-13T11:13:30.839Z Starting sync process for account USER@DOMAIN@URL
2021-09-13T11:13:30.878Z onSyncStart: begin
2021-09-13T11:13:30.878Z https://URL/webdav/floccus_bookmarks/Admin/bookmarks.xbel.lock
2021-09-13T11:13:31.105Z https://URL/webdav/floccus_bookmarks/Admin/bookmarks.xbel.lock
2021-09-13T11:13:31.177Z Syncing failed with E019: HTTP status 404. Failed PUT request. Check your server configuration and log.
2021-09-13T11:13:31.180Z onSyncFail

FYI: Seafile release a patch to fix "[fix] Fix WebDAV error if a file is moved immediately after uploading". This may be related to the problem.
But still I would expect floccus to detect sync errors.

Apart from that it showed that it tried setting/getting the .lock file and nothing more.

Additional context

I hope that there is room for improvement with the webdav sync algo and to detect if there are sync issues. Maybe with some kind of checksum file stored in the server where the bookmarks file is actually stored.
The lock file makes sense but sometimes it seems that floccus cannot remove it, whereas other webdav applications can just edit the file manually and it just works.

Also this error sometimes messed up all bookmarks, maybe because floccus actually thinks that everything is fine, when in fact it is not.

Thanks!

Originally created by @DerDanilo on GitHub (Sep 13, 2021). Original GitHub issue: https://github.com/floccusaddon/floccus/issues/956 ### Describe the bug Sometimes the webdav sync seems to be broken. On some occasions floccus reported that everything was fine and synced, when in fact, nothing was fine. Trying a manual sync didn't solve the issues either. Restarting the browser, checking network connections etc. didn't solve the issue either. ### To Reproduce Steps to reproduce the behavior: - Setup floccus sync with webdav backend - Start using it - Wait for the error (not syncing bookmarks, while telling everything is fine) to appear randomly - OR: Wait for all bookmarks are messed up because of IDK; sync issues with a webdav backend?! - Freak out because all bookmarks are messed up - Remember that you have file versioning enabled, restore old version of bookmark sync, reset bookmarks, start syncing from zero ### Expected behavior Floccus should detect if there is a sync error and report it. This seems either a sync issue or the algo doesn't properly detect if there is a sync error. ### Desktop - OS: Linux, Windows, Mac (all the same) - Browser chrome and firefox - Browser Version: various - Floccus version: 4.7; but the problem existis since I started using floccus last year. - Floccus sync method: webdav, nextcloud bookmark app couldn't handle the amount of bookmarks ### Server (please complete the following information) - OS: Debian 10 - Nextcloud version: [if applicable] - Seafile CE WebDAV : 7 and 8; but this should not be relevant I think since it works with other Seafile servers running the same versions and config - Bookmarks app version: [if applicable] Note: Please write down the actual version numbers instead of writing 'latest'. ### Debug log Sometimes the following error appears once one starts trying to force a sync (dangerous actions) ``` 2021-09-13T11:13:30.839Z Starting sync process for account USER@DOMAIN@URL 2021-09-13T11:13:30.878Z onSyncStart: begin 2021-09-13T11:13:30.878Z https://URL/webdav/floccus_bookmarks/Admin/bookmarks.xbel.lock 2021-09-13T11:13:31.105Z https://URL/webdav/floccus_bookmarks/Admin/bookmarks.xbel.lock 2021-09-13T11:13:31.177Z Syncing failed with E019: HTTP status 404. Failed PUT request. Check your server configuration and log. 2021-09-13T11:13:31.180Z onSyncFail ``` FYI: Seafile release a patch to fix "[fix] Fix WebDAV error if a file is moved immediately after uploading". This may be related to the problem. But still I would expect floccus to detect sync errors. Apart from that it showed that it tried setting/getting the .lock file and nothing more. ### Additional context I hope that there is room for improvement with the webdav sync algo and to detect if there are sync issues. Maybe with some kind of checksum file stored in the server where the bookmarks file is actually stored. The lock file makes sense but sometimes it seems that floccus cannot remove it, whereas other webdav applications can just edit the file manually and it just works. Also this error sometimes messed up all bookmarks, maybe because floccus actually thinks that everything is fine, when in fact it is not. Thanks!

kerem

2026-02-25 22:37:39 +03:00

closed this issue
added the
bug

correctness issues
labels

kerem commented

2026-02-25 22:37:40 +03:00

Author

Owner

@mnalis commented on GitHub (Sep 13, 2021):

@DerDanilo Can you elaborate what exactly does the "nothing was fine" mean? Did it erase all bookmarks on the nextcloud? Did it erase all bookmarks in the browser? Did it crash the browser? Something else? What exactly? It would be great if you could provide example how it looked before sync, and how it looks after sync. Or at least explain in detail what exactly happens, what was the difference, and why were you unhappy with the results.

To the best of my knowledge, floccus does look at the error codes returned by the server and tries to handle them appropriately. There might be a bug in the floccus (or in the server) that causes that to fail, but troubleshooting that needs much more information. Or you might have older buggy version of floccus active somewhere which interferes.

What I would do is:

disable floccus on all browsers
if possible, change password / revoke app permissions you gave to floccus instances (in order to prevent other instances interefering if you forgot some floccus instance)
remove file on WebDAV server (backup it first).
choose one (and only one!) browser
- backup browser bookmarks (always a good idea)
- upgrade floccus to latest version on that browser
- delete floccus account
- recreate floccus account
- try to sync and see if that works.
if (and only if) syncs work perfectly every time you try it, then go redo step (4) with another browser.
If sync didn't work as you think it would; describe exactly which browser and floccus version and server version it is that failed, as well as what exactly happened (and why that looks wrong), with logs of both floccus and the server, and mention on how many browsers did you enable floccus on before it started misbehaving.

@mnalis commented on GitHub (Sep 13, 2021): @DerDanilo Can you elaborate what **exactly** does the _"nothing was fine"_ mean? Did it erase all bookmarks on the nextcloud? Did it erase all bookmarks in the browser? Did it crash the browser? Something else? What exactly? It would be great if you could provide example how it looked before sync, and how it looks after sync. Or at least explain _in detail_ what exactly happens, what was the difference, and why were you unhappy with the results. To the best of my knowledge, floccus does look at the error codes returned by the server and tries to handle them appropriately. There might be a bug in the floccus (or in the server) that causes that to fail, but troubleshooting that needs much more information. Or you might have older buggy version of floccus active somewhere which interferes. What I would do is: 1. disable floccus on **all browsers** 2. if possible, change password / revoke app permissions you gave to floccus instances (in order to prevent other instances interefering if you forgot some floccus instance) 3. remove file on WebDAV server (backup it first). 4. choose one (and **only one**!) browser - backup browser bookmarks (always a good idea) - upgrade floccus to latest version on that browser - delete floccus account - recreate floccus account - try to sync and see if that works. 5. if (and only if) **syncs work perfectly every time you try it**, then go redo step (4) with another browser. 6. If sync didn't work as you think it would; describe exactly which browser and floccus version and server version it is that failed, as well as what exactly happened (and why that looks wrong), with logs of both floccus and the server, and mention on how many browsers did you enable floccus on before it started misbehaving.

kerem commented

2026-02-25 22:37:40 +03:00

Author

Owner

@DerDanilo commented on GitHub (Sep 18, 2021):

Thanks for your patience, very busy these days. Please be assured that I'll answer to your questions even if it may take a couple of weeks sometimes. Excuse me for the switch between I and we, which might be confusing sometimes. Floccus is awesome and I am really happy about this product!

Easy things first: We basically did what you suggested in your list to resolve the issue, being happy having file versioning and therefore a way to jump back a few days where everything was fine. It is still a mess and requires a lot of time to clean up.

I cannot really show examples of what had happend because I didn't create any screenshots and this might also be a GDRP violation. Anyways I'll try to explain in more details.

Basically bookmarks were suddenly messed up. Bookmarks from one folder were in another folder. Already deleted bookmarks were back, some in the folder they were before, some in another folder were they don't belong. Renamed bookmarks were present with their old and their new name. Having a couple of thousand bookmarks one can imagine the mess with something like this. The 50% safety didn't trigger so floccus doesn't seem to have detected those severe differences.

Sometimes floccus is unresponsive and even crashes the browser. A forced browser restart is the only thing that brings back floccus (and the browser). This is valid for all systems we use (Linux, Mac and Windows).

Then there is also the problem that floccus syncs (automatic or manual) and confirms a successfull sync, but in fact it did nothing. No file change on the server side and nothing really in the floccus logs except something like "writing .lock...". But even the lock file was not written on the server. All this while other applications work just fine with webDAV to the same target. I would expect floccus to make sure that it did really sync and throw an error if there was no real sync. Restarting the webbrowser did solve the issue sometimes but not always so I'd rule that mostly out.
Maybe it could read the bookmark file again after a sync, looking for a timestemp or version mark or something.

General information:

We are always using the latest stable version of floccus on all systems. Extension auto update is enabled in all browsers
We are using Firefox, Chrome, Chromium and Edge
Browser integrated Bookmark sync is disabled whenever possible or was never actiaved in the first place - to avoid collision
I am using floccus to keep bookmarks in sync between different browser and workstations (Linux Desktop, Macbook, Windows Desktop, virtual Workstation)
Initially all systems were donor and receiver, merging all bookmarks. After the second sync mess I decided to go for a single donor in one browser (firefox), making all others receivers only. This is no optimal but seems to solve part of the problem for now.
Usually I am only working with one system at the time, the only exeption being the virtual workstations since it's always running.
Sync intervall is set to different times on all systems to avoid conflicts by systems syncing at the same time
I use one master bookmark profile that syncs all bookmarks, including all other accounts that are syncing subfolders
Additional profiles all sync only a single subfolder and to different servers
Additional profiles have of course the option enabled to allow sync by a parent profile/folder
We are only syncing bookmarks from the bookmark toolbar
For now people wanting to sync subfolders via floccus are advised to just download the bookmarks. But since floccus wants to set the .lock file people require write access to the WebDAV share; otherwise we found the sync won't work
Highest Number of users are smaller teams of up to 5 members, never more. But we'd expect floccus to also be able to sync that if it's read-only

Here are some more infos about our webDAV targes:

WebDAV targets are not clear on how floccus evaluates the URL and folder path. Some profiles may have a slash and the end when another one cannot be saved because flocuss refuses to do so. So I'd expect floccus to just handle whatever is configues are URL and either add a slash if missing or use the already existing one if entered. The same goes for the path with a leading slash.
All profiles are using WebDAV as target, most of them being Seafile Servers
There were some WebDAV issues with certain Seafile Server version but the problem were still happening for some profiles with Seafile Server being the same version and similiar if not the same config (nginx, proxy etc.)
(We are not using Nextcloud since it was incapable of handling that many bookmarks and made more problems than it could solve. Not bashing Nextcloud but this is just a fact. --> We have decent servers with plenty of CPU, RAM and PHP config, so that is no the problem.)

This is a lot of information that you may be able to work with already.
Thanks for your time improving the floccus.

@DerDanilo commented on GitHub (Sep 18, 2021): Thanks for your patience, very busy these days. Please be assured that I'll answer to your questions even if it may take a couple of weeks sometimes. Excuse me for the switch between I and we, which might be confusing sometimes. Floccus is awesome and I am really happy about this product! Easy things first: We basically did what you suggested in your list to resolve the issue, being happy having file versioning and therefore a way to jump back a few days where everything was fine. It is still a mess and requires a lot of time to clean up. I cannot really show examples of what had happend because I didn't create any screenshots and this might also be a GDRP violation. Anyways I'll try to explain in more details. Basically bookmarks were suddenly messed up. Bookmarks from one folder were in another folder. Already deleted bookmarks were back, some in the folder they were before, some in another folder were they don't belong. Renamed bookmarks were present with their old and their new name. Having a couple of thousand bookmarks one can imagine the mess with something like this. The 50% safety didn't trigger so floccus doesn't seem to have detected those severe differences. Sometimes floccus is unresponsive and even crashes the browser. A forced browser restart is the only thing that brings back floccus (and the browser). This is valid for all systems we use (Linux, Mac and Windows). Then there is also the problem that floccus syncs (automatic or manual) and confirms a successfull sync, but in fact it did nothing. No file change on the server side and nothing really in the floccus logs except something like "writing .lock...". But even the lock file was not written on the server. All this while other applications work just fine with webDAV to the same target. I would expect floccus to make sure that it did really sync and throw an error if there was no real sync. Restarting the webbrowser did solve the issue sometimes but not always so I'd rule that mostly out. Maybe it could read the bookmark file again after a sync, looking for a timestemp or version mark or something. General information: - We are always using the latest stable version of floccus on all systems. Extension auto update is enabled in all browsers - We are using Firefox, Chrome, Chromium and Edge - Browser integrated Bookmark sync is disabled whenever possible or was never actiaved in the first place - to avoid collision - I am using floccus to keep bookmarks in sync between different browser and workstations (Linux Desktop, Macbook, Windows Desktop, virtual Workstation) - Initially all systems were donor and receiver, merging all bookmarks. After the second sync mess I decided to go for a single donor in one browser (firefox), making all others receivers only. This is no optimal but seems to solve part of the problem for now. - Usually I am only working with one system at the time, the only exeption being the virtual workstations since it's always running. - Sync intervall is set to different times on all systems to avoid conflicts by systems syncing at the same time - I use one master bookmark profile that syncs all bookmarks, including all other accounts that are syncing subfolders - Additional profiles all sync only a single subfolder and to different servers - Additional profiles have of course the option enabled to allow sync by a parent profile/folder - We are only syncing bookmarks from the bookmark toolbar - For now people wanting to sync subfolders via floccus are advised to just download the bookmarks. But since floccus wants to set the .lock file people require write access to the WebDAV share; otherwise we found the sync won't work - Highest Number of users are smaller teams of up to 5 members, never more. But we'd expect floccus to also be able to sync that if it's read-only Here are some more infos about our webDAV targes: - WebDAV targets are not clear on how floccus evaluates the URL and folder path. Some profiles may have a slash and the end when another one cannot be saved because flocuss refuses to do so. So I'd expect floccus to just handle whatever is configues are URL and either add a slash if missing or use the already existing one if entered. The same goes for the path with a leading slash. - All profiles are using WebDAV as target, most of them being Seafile Servers - There were some WebDAV issues with certain Seafile Server version but the problem were still happening for some profiles with Seafile Server being the same version and similiar if not the same config (nginx, proxy etc.) - (We are not using Nextcloud since it was incapable of handling that many bookmarks and made more problems than it could solve. Not bashing Nextcloud but this is just a fact. --> We have decent servers with plenty of CPU, RAM and PHP config, so that is no the problem.) This is a lot of information that you may be able to work with already. Thanks for your time improving the floccus.

kerem commented

2026-02-25 22:37:40 +03:00

Author

Owner

@mnalis commented on GitHub (Sep 18, 2021):

@DerDanilo it seems that there are multiple groups of people using multiple floccus instances on multiple servers. Which is great (that you have many of them using floccus, not that they are having problems)! But for debugging the problem, it makes it very hard if not impossible to try to debug something with such a broad scope.

I would thus advise you to find one simplest case/configuration where the problem happens, and then it becomes possible for developers to try to debug that one case.

So out of that group of people/browsers that have the problems; it would be best if you would try to find one case in which:

you can reliably reproduce a problem (ideally, problem happens every single time you try it, or at least very often - and not only once in a month for example).
you can easily access that system(s) and try different things on them (install new versions of extensions, trying manual commands, backing up and restoring the bookmarks etc.) preferably without much disrupting the work being done on those systems
is simplest and most up-to-date in its configuration, specifically:
- minimal number of browsers involved doing the sync - ideally one (but it is likely you might need two to reproduce the problem - but please make it as little as possible, and not for example 20 browsers, as it would be more than 20 times harder to find a problem then).
- if more than one browser must be involved for error to happen, it would be best if that would be same maker of browser (eg. 2 firefoxes are better then 1 firefox + 1 chrome). If possible, it is preferred that the browser version is the same too.
- latest version of both the server software and client software are preferred.
- ideally if you can reproduce the problem with small number of bookmarks (instead with a huge number)
- ideally if you can reproduce the problem with bookmarks you can share without GDPR problems. (so if you can reproduce the problem on test system setup account made specifically for that purpose is ideal). It is not impossible to debug if that is real-life bookmarks you can't share, but it makes is harder both to person trying to see what is happening, and to you as you'd need to semi-manually anonymize and verify the logs are sufficiently anonymized, which takes much more time and effort.

When you choose that one case, than you will know exactly the version of browsers, server etc. (and can reported them in this bug) and proceed with instructions given before.

Only when the problem is (hopefully) found and fixed at that one case, can you proceed to see if that fixes all the other cases for other users too, or are there some other bugs that remain in some of them (in which case whole procedure would be repeated again with one new test case)

@mnalis commented on GitHub (Sep 18, 2021): @DerDanilo it seems that there are multiple groups of people using multiple floccus instances on multiple servers. Which is great (that you have many of them using floccus, not that they are having problems)! But for debugging the problem, it makes it very hard if not impossible to try to debug something with such a broad scope. I would thus advise you to find _**one** simplest case/configuration where the problem happens_, and then it becomes possible for developers to try to debug that one case. So out of that group of people/browsers that have the problems; it would be best if you would try to find **one case** in which: - you can reliably reproduce a problem (ideally, problem happens every single time you try it, or at least very often - and not only once in a month for example). - you can easily access that system(s) and try different things on them (install new versions of extensions, trying manual commands, backing up and restoring the bookmarks etc.) preferably without much disrupting the work being done on those systems - is simplest and most up-to-date in its configuration, specifically: - minimal number of browsers involved doing the sync - ideally one (but it is likely you might need two to reproduce the problem - but please make it as little as possible, and not for example 20 browsers, as it would be more than 20 times harder to find a problem then). - if more than one browser must be involved for error to happen, it would be best if that would be same maker of browser (eg. 2 firefoxes are better then 1 firefox + 1 chrome). If possible, it is preferred that the browser version is the same too. - latest version of both the server software and client software are preferred. - ideally if you can reproduce the problem with small number of bookmarks (instead with a huge number) - ideally if you can reproduce the problem with bookmarks you can share without GDPR problems. (so if you can reproduce the problem on test system setup account made specifically for that purpose is ideal). It is not impossible to debug if that is real-life bookmarks you can't share, but it makes is harder both to person trying to see what is happening, and to you as you'd need to [semi-manually anonymize](https://github.com/floccusaddon/floccus/issues/912#issuecomment-881459667) and verify the logs are sufficiently anonymized, which takes much more time and effort. When you choose that **one** case, than you will know exactly the version of browsers, server etc. (and can reported them in this bug) and proceed with [instructions given before](https://github.com/floccusaddon/floccus/issues/956#issuecomment-918627637). Only when the problem is (hopefully) found and fixed at that **one case**, can you proceed to see if that fixes all the other cases for other users too, or are there some **other bugs** that remain in some of them (in which case whole procedure would be repeated again with **one** new test case)

kerem commented

2026-02-25 22:37:40 +03:00

Author

Owner

@DerDanilo commented on GitHub (Sep 23, 2021):

Thanks for your time to check this in detail. However I don't have the time currently to do all those tests. It may take several month until I can post more information. I saw some other posts that reported issues with webdav that looked quiet similar, maybe some of those may already point into the right direction.

Hint: To what I can say already most problems seem to have to do with the .lock file not being written/read/deleted correctly when using webdav.

I'll post more info once I find time. Thanks for your patience in advance!

@DerDanilo commented on GitHub (Sep 23, 2021): Thanks for your time to check this in detail. However I don't have the time currently to do all those tests. It may take several month until I can post more information. I saw some other posts that reported issues with webdav that looked quiet similar, maybe some of those may already point into the right direction. Hint: To what I can say already most problems seem to have to do with the .lock file not being written/read/deleted correctly when using webdav. I'll post more info once I find time. Thanks for your patience in advance!

kerem commented

2026-02-25 22:37:40 +03:00

Author

Owner

@creesch commented on GitHub (Sep 27, 2021):

Hint: To what I can say already most problems seem to have to do with the .lock file not being written/read/deleted correctly when using webdav.

I might have a small bit of additional information. I used to have nextcloud set up with desktop sync and had floccus syncing to both the bookmarks app and to the file through webdav as backup (as the bookmarks app doesn't have versioning). From time to time the nextcloud desktop app would report issues with the bookmarks lock file. This did seem to coincide with it attempting to sync during or shortly after floccus did sync bookmarks.

I haven't enabled webdav sync of bookmarks anymore but I think that anyone who wants to look into the issue should be able to reproduce it this way.

@creesch commented on GitHub (Sep 27, 2021): > Hint: To what I can say already most problems seem to have to do with the .lock file not being written/read/deleted correctly when using webdav. I might have a small bit of additional information. I used to have nextcloud set up with desktop sync and had floccus syncing to both the bookmarks app and to the file through webdav as backup (as the bookmarks app doesn't have versioning). From time to time the nextcloud desktop app would report issues with the bookmarks lock file. This did seem to coincide with it attempting to sync during or shortly after floccus did sync bookmarks. I haven't enabled webdav sync of bookmarks anymore but I think that anyone who wants to look into the issue should be able to reproduce it this way.

kerem commented

2026-02-25 22:37:40 +03:00

Author

Owner

@dmotte commented on GitHub (Jul 27, 2022):

I think I have found the cause of this problem.

My setup: NGINX as WebDAV server and Floccus on Chrome.

Looking at the NGINX logs, I noticed that sometimes the server response status is 304 Not Modified even if the file changed:

::1 - myuser [26/Jul/2022:15:52:01 +0200] "GET /bookmarks.xbel.lock HTTP/1.1" 404 197 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36"
::1 - myuser [26/Jul/2022:15:52:01 +0200] "PUT /bookmarks.xbel.lock HTTP/1.1" 201 0 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36"
::1 - myuser [26/Jul/2022:15:52:01 +0200] "GET /bookmarks.xbel HTTP/1.1" 304 0 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36"
::1 - myuser [26/Jul/2022:15:52:01 +0200] "DELETE /bookmarks.xbel.lock HTTP/1.1" 204 0 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36"

So I tried to edit my NGINX configuration to prevent 304 responses as a workaround. This is my location / config section:

location / {
    dav_methods PUT DELETE MKCOL COPY MOVE;
    dav_ext_methods PROPFIND OPTIONS;
    dav_access user:rw group:rw all:rw;

    client_max_body_size 0;
    create_full_put_path on;
    client_body_temp_path /tmp/;

    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;

    if_modified_since off;
    add_header Last-Modified "";
    expires -1;
    add_header Cache-Control no-store;
}

Notice the last 4 lines. Now everything is working! :)

BTW I think that this problem should be handled client-side by Floccus, maybe by setting the Pragma: no-cache and Cache-Control: no-cache headers for every GET request (see https://stackoverflow.com/a/29246795). These are the headers set by Chrome when the user presses CTRL+F5 to reload a web page. In this way the server won't reply 304 again because we are explicitly requesting to retransmit the whole bookmarks.xbel file content.

I think that a possible fix would be adding the noted headers to the downloadFileWeb and downloadFileNative functions of the file src/lib/adapters/WebDav.ts file. Let me know what you think 😉

@dmotte commented on GitHub (Jul 27, 2022): I think I have found the cause of this problem. My setup: **NGINX** as **WebDAV** server and Floccus on **Chrome**. Looking at the NGINX logs, I noticed that sometimes the server response status is `304 Not Modified` even if the file changed: ``` ::1 - myuser [26/Jul/2022:15:52:01 +0200] "GET /bookmarks.xbel.lock HTTP/1.1" 404 197 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36" ::1 - myuser [26/Jul/2022:15:52:01 +0200] "PUT /bookmarks.xbel.lock HTTP/1.1" 201 0 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36" ::1 - myuser [26/Jul/2022:15:52:01 +0200] "GET /bookmarks.xbel HTTP/1.1" 304 0 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36" ::1 - myuser [26/Jul/2022:15:52:01 +0200] "DELETE /bookmarks.xbel.lock HTTP/1.1" 204 0 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36" ``` So I tried to edit my NGINX configuration to prevent `304` responses as a **workaround**. This is my `location /` config section: ``` location / { dav_methods PUT DELETE MKCOL COPY MOVE; dav_ext_methods PROPFIND OPTIONS; dav_access user:rw group:rw all:rw; client_max_body_size 0; create_full_put_path on; client_body_temp_path /tmp/; auth_basic "Restricted"; auth_basic_user_file /etc/nginx/.htpasswd; if_modified_since off; add_header Last-Modified ""; expires -1; add_header Cache-Control no-store; } ``` Notice the last 4 lines. Now everything is working! :) BTW I think that this problem should be handled client-side by _Floccus_, maybe by setting the `Pragma: no-cache` and `Cache-Control: no-cache` headers for every `GET` request (see https://stackoverflow.com/a/29246795). These are the headers set by Chrome when the user presses `CTRL+F5` to reload a web page. In this way the server won't reply `304` again because we are explicitly requesting to retransmit the whole `bookmarks.xbel` file content. I think that a possible fix would be adding the noted headers to the `downloadFileWeb` and `downloadFileNative` functions of the file [`src/lib/adapters/WebDav.ts`](https://github.com/floccusaddon/floccus/blob/develop/src/lib/adapters/WebDav.ts) file. Let me know what you think :wink:

kerem commented

2026-02-25 22:37:40 +03:00

Author

Owner

@marcelklehr commented on GitHub (Jul 27, 2022):

Wow, this is a great find! Thank you for taking the time to look into this!

I think that this problem should be handled client-side by Floccus

I think technically if you run a web server that caches stuff, you're responsible that it doesn't cache stuff it shouldn't cache. HTTP doesn't specify that everything should be cached by default. But I see that this is a problem that people are far too likely to run into with floccus to not take it into account.

I think that a possible fix would be adding the noted headers to the downloadFileWeb and downloadFileNative functions of the file src/lib/adapters/WebDav.ts file. Let me know what you think wink

If you'd be willing to submit a pull request that would be awsome ❤️

@marcelklehr commented on GitHub (Jul 27, 2022): Wow, this is a great find! Thank you for taking the time to look into this! > I think that this problem should be handled client-side by Floccus I think technically if you run a web server that caches stuff, you're responsible that it doesn't cache stuff it shouldn't cache. HTTP doesn't specify that everything should be cached by default. But I see that this is a problem that people are far too likely to run into with floccus to not take it into account. > I think that a possible fix would be adding the noted headers to the downloadFileWeb and downloadFileNative functions of the file [src/lib/adapters/WebDav.ts](https://github.com/floccusaddon/floccus/blob/develop/src/lib/adapters/WebDav.ts) file. Let me know what you think wink If you'd be willing to submit a pull request that would be awsome :heart:

kerem commented

2026-02-25 22:37:40 +03:00

Author

Owner

@dmotte commented on GitHub (Jul 30, 2022):

@marcelklehr thanks! Sorry for the late reply. I will try to submit a pull request in the next days :)

@dmotte commented on GitHub (Jul 30, 2022): @marcelklehr thanks! Sorry for the late reply. I will try to submit a pull request in the next days :)

kerem commented

2026-02-25 22:37:40 +03:00

Author

Owner

@github-actions[bot] commented on GitHub (Aug 5, 2023):

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions[bot] commented on GitHub (Aug 5, 2023): This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

kerem referenced this issue

2026-02-25 23:30:28 +03:00

[PR #624] [CLOSED] Bump mocha from 7.1.2 to 8.1.1 #1668

Rows
Columns

[GH-ISSUE #956] WebDAV Sync problems #624

Describe the bug

To Reproduce

Expected behavior

Desktop

Server

Debug log

Additional context