TW WebDAV Failing Status 412 - but not curl

[Kevin Kleinfelter]

I'm trying TW from an Apache WebDAV server.  I'm getting

    Error while saving:

    XMLHttpRequest error code: 412

All I did was to load a brand new TW file into my browser via http://192.168.1.2/webdav/testfile.html, add a new tiddler, and let the auto-save do its thing.  I did no concurrent updating from another browser or on the server.  I tried 3 times (starting with a new browser each time).

I *think* my WebDAV is configured correctly:

• I connected to it via Mac Finder, and added/deleted/renamed files without error.
• I was able to retrieve a file via: curl --user "userid:password" http://myserver/webdav/testfile.html --digest -o testfile.html
• I was able to put a file via: curl --user "userid:password" http://myserver/webdav/ --upload-file testfile.html --digest

When I look at the Apache access log I notice these two PUTs (first is the TW put; second is the curl put):

• "PUT /webdav/testfile.html HTTP/1.1" 412 558 "http://192.168.1.2/webdav/testfile.html" "Mozilla/5.0 blah-blah"
  
• "PUT /webdav/testfile.html HTTP/1.1" 204 289 "-" "curl/7.54.0"
  

Clearly, the difference in the PUT request formats triggers a 412 error when TW PUTs the data.

The Apache webdav and DavLock folders are owned and writable by www-data.  The DavLock db and the document files are owned and writable by www-data.

What am I doing wrong?  

TIA

[Kevin Kleinfelter]

I dumped the headers.  The key difference is that TW sends an "If-Match" header, and curl doesn't.

So Apache is saying that the file doesn't match the digest sent by TW.  This happens whether I use Safari, Chrome, or IE.

I reloaded the page, and I tried to save it again.  The value in the If-Match was the same before/after the page reload.  I think that's evidence that the file did not change.

I'm using the latest (just downloaded today) TW.

Any ideas for how to make TW WebDav work?

TIA

[TonyM]

Kevin,

I had WedDav working on Windows but have not used it lately. What I do remember is problems in TiddlyServer that sound a little like what you are experiencing, Arlen included a setting to allow a 3 second window ""etagWindow": 3,

Until I set this I was always getting 412 errors 

No answer I am sorry, but this may give a clue.

Regards

Tony

[Lost Admin]

I ran into this problem last year. You aren't doing anything wrong. The reason for this happening is simple. Apache (and IIS) do not sent an updated etag value with the response to the PUT request (webdav save method) because you can add post-processing to the PUT request that would change the file (common with things like GIT where change headers are added). This means that the Apache (and IIS) can't be positive that the file that would be sent for a subsequent GET request would be identical to what was sent with the PUT request. So, it is inappropriate for the web server to include the etag header in the response to the PUT request.

The client application (tiddlywiki running in your browser) should follow-up the PUT request with a GET request to get an update to the tiddlywiki file after the PUT finishes to ensure that all affected changes are reflected in what you have in your browser. This would also provide an updated etag value and solve the 412 issue.

I have tested the above with Firefox, Chrome, IE, and Safari on Windows, Linux, and OSX (where the software was available to me) with the Apache web server (version 2.4) running on Linux, FreeBSD, Windows 7, and Windows 10 as well as IIS running on both Windows 7 and Windows 10. They all behave the same way.

There was discussion of this many months ago on groups. https://groups.google.com/forum/#!searchin/tiddlywiki/webdav$20etag$20thelostadmin%7Csort:date/tiddlywiki/8HB0R_ADYac/AMyHtqO2AAAJ

The only reliable work-around I've found to-date is to reload the web page after each save of tiddlywiki.

My Apache web server uses WebDav for tiddlywiki and I use the post-processing to make a backup (similar to how tiddlyspot has a backup directory) of changes to the files. It's not available for general use because of the etag issue.

On Monday, April 2, 2018 at 2:20:25 PM UTC-4, Kevin Kleinfelter wrote:

[Kevin Kleinfelter]

Thanks for the replies.  Now that I know that's just how it works, I decided to hack the code and

change

if(this.etag) {\n\t\theaders[\"If-Match

to

if(false) {\n\t\theaders[\"If-Match

I'll lose race-condition prevention, but it's a single-user wiki and I prioritize low-friction use in this case.

[Rick Nyman]

Resurrecting an old thread, but this solved the same issue for me, so thank you!

Rick