The situation regarding If-None-Match is as follows.
Reason why setting of this header was included is described in WebDavApi.js(lines 363-371) - to resolve the issue with iOS network lib and Seafile WebDAV implementation.
mailbox.org WebDAV server doesn’t like valid(quoted) If-None-Match header. If it’s present, server returns HTTP status code 200 with empty body to PROPFIND requests instead of expected 207 Multi-Status. But mailbox.org WebDAV server either ignores or accepts invalid(unquoted) If-None-Match header.
Apache Tomcat doesn’t accept requests with invalid(unquoted) and returns 400 Bad request.
What do you think is best way to resolve the issue?
To be honest I can’t think of any solution which is not risky other than adding a boolean setting to toggle this behaviour for webdav connections.
Laurent did say that’s not ideal because it’s not easily discovered, but maybe rather than making it an advanced setting, we could make it a non advanced setting so it is visible by default. In addition, we could give the setting a generic and high level name such as ‘Enable strict standard for headers’, to avoid being too specific about the implementation details.
Ideally this new setting should be enabled by default for new installations, but disabled for existing ones currently using WebDAV sync. This is possible in a migration script by checking the currently selected sync target and setting the value upon migration.
Right sorry. I look into this at some point and my conclusion is that ideally we'd get rid of this hacky header but I'm worried to break something else if we do this
Do some webdav servers mandate that the If-None-Match header is supplied?
Exerpt from the answer:
Some WebDAV servers intentionally enforce stricter preconditions than the RFC strictly requires.
Common cases:
1. PUT to create a new resource
Many servers require:
If-None-Match: *
Meaning:
“Only create this resource if it does not already exist.”
If you omit it, the server may return:
412 Precondition Failed
or 409 Conflict
This is allowed by the spec as a safety policy, even though it’s not mandatory.
@laurent So it sounds to me like it would be risky to remove the header entirely
I’ve tested how three different WebDAV implementations(SeaFile 13.0.15 CE, mailbox.org, Tomcat 11.0.15) behave with regard to If-None-Match header(either absent, unquoted, quoted) . Test consisted of importing welcome files into empty profile, reuploading local data to sync target, then making a few simple changes and syncing them. As a client I’ve used latest source code on Win11. Here are results
Latest CE edition of SeaFile doesn’t care about If-None-Match at all. Looks like the the original issue, which prompted setting If-None-Match header, was resolved on server side as well.
Apache Tomcat 11 rejects requests with unquoted If-None-Match with response 400 Bad Request
mailbox.org server responds to requests with quoted If-None-Match header with status code 200 with empty body.
Since all three WebDAV implementation worked correctly with Joplin when If-None-Match was not being set, it seems to me, that best way to resolve the issue would be
keep default behaviour as is
add a checkbox into advanced settings, that would disable setting If-None-Match header.
I’ve also prepared a temporary solution, a checkbox in advanced settings, which gives user an option to disable setting of If-None-Matched header. Default behavior is unchanged, therefore it shouldn’t break anything. Is this acceptable for you? If so, I’ll submit it as a pull request.
@horvat If you already have a code change with this solution ready, I’d suggest creating the PR and see what happens in review. The PR’s will be a work queue for reviewing, whereas a forum topic can easily get lost
Looking back at the AI answer about removing the If-None-Match header, I realise that actually the Joplin code does not send the value as * currently, but instead sends a 'purposely invalid string' according to the code comment. So in such scenarios that a WebDAV server actually requires the If-None-Match header, it is very likely still going to fail anyway, which suggests we don't have existing users using a WebDAV server with a specific requirement for the header to be supplied.
If not needed anymore then straight out removing the header should be the way to go. But if it is still needed, than maybe only add the header if the word 'seafile' is present in the url? It is possible to make a custom domain on Seafile which won't contain seafile in the url, but given that the Seafile header requirement doesn't follow the RFC standard, maybe we could require Seafile users to use a non custom domain in order to make Joplin standards compliant for all other servers?