Could someone help me a bit with something? My coding skills are not up to even this simple task sadly.
The WebDAV saver for TiddlyWiki saves using the HTTP PUT method. Unfortunately the Apache and IIS implementations of WebDAV do not respond with the updated ETag header. However, according to the documentation, the HTTP HEAD method should respond with the new ETAG. So, I would like to modify the WebDAV saver to do the following: 1) call the HTTP LOCK method to lock the file 2) call the HTTP PUT method to save the file (as it does today with the ETAG and everything) 3) If save fails: return the error message (like we do today) 4) if save succeeds: call the HTTP HEAD method to get the updated ETag 5) call the HTTP UNLOCK method to release the lock on the file NOTES: If I read the documentation correctly, HTTP locks have a timeout. So if an issue occurs during the locked phase, the file should be released in a few minutes. I'm not bothering to actually check if we got a lock after step 1 because we will still get an error from the PUT call due to either another file lock or the ETag miss-match. The UNLOCK response doesn't need to be communicated to the end-user because it should only fail if the initial lock failed (or there is some miss-match in the lock token). This could even be done asynchronously. We could conceivably use the HTTP LOCK method to lock a tiddlywiki when it is being edited but the LOCK method has a timeout, so we would need to periodically re-request the lock. Right now I prefer the opportunistic locking method we are using with ETag. The only reason to use the lock around the PUT and HEAD calls is to ensure that the ETag we get is the one that matches the data we just saved and not the data submitted by another person at almost the same time. In Apache, the lock method is optional and requires some additional set-up. By ignoring the success/failure of the lock, we nicely fall-back to the current ETag method. Thoughts? Suggestions? Pointers to where I find the parts of the WebDAV saver code in tiddlywiki to attempt to make these changes myself? On Thursday, September 7, 2017 at 4:59:40 PM UTC-4, Arlen Beiler wrote: > > Ok, so how *does* web dav take care of making sure someone is editing the > latest version? Or does it use the entirely file-system concept of locking > files for editing? > > Are we barking up the wrong tree with the idea of using web DAV? It is > entirely file system centered. The fact that it can handle web requests > seems almost incidental. Or maybe it is just the simple fact that the PUT > saver nowhere near implements the entire DAV protocol. > > What protocol talks about Etags in 204 responses? The one I found only > mentions it once in relation to a PUT request by saying that there is no > specific definition of whether it should guarantee the file content is > exactly byte-for-byte identical to the PUT request. > http://www.ietf.org/rfc/rfc4918.txt > > The HTTP/1.1 spec is at https://www.ietf.org/rfc/rfc2616.txt > > I can't find anything in either of those just by searching for "etag". > > Just some thoughts. > > On Thu, Sep 7, 2017 at 10:48 AM, Lost Admin <[email protected] > <javascript:>> wrote: > >> I've been trying to dig into the proper specs on the use of ETag and it >> looks like it is only supposed to be sent from the server along with the >> data. Thus the PUT request is not supposed to include a new ETag. I >> *think* Apache is actually doing it right. >> >> Also, I did the same series of screenshots on my test Lighttpd server >> (which doesn't experience the same 412 error) and for some reason, the >> If-Match header gets dropped from the subsequent PUT requests headers. I >> don't know why it would be different as I think that header is coming from >> the client side. >> >> >> On Tuesday, September 5, 2017 at 9:18:07 AM UTC-4, Arlen Beiler wrote: >>> >>> It is becoming pretty clear that for some reason the Etag is not being >>> set in the response header, nor anything else equivalent to it. Per our >>> discussion privately, it does seem that this is an Apache issue, however I >>> have not been able to look into it further. >>> >>> A couple of articles which touch on this: >>> >>> - >>> >>> https://fullstackhack.wordpress.com/2014/12/10/the-pain-of-etags-mod_deflate-apache-2-4-and-tomcat-7/ >>> >>> - https://httpd.apache.org/docs/2.4/caching.html >>> >>> At some point I will test it on one of my servers and see if I can get >>> it working. However, it is obvious that this is the problem. One option >>> would be to make a second head request if the 204 response does not contain >>> an Etag, but I guess that wouldn't be atomic either. >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "TiddlyWiki" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> Visit this group at https://groups.google.com/group/tiddlywiki. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/tiddlywiki/a827b52a-100c-453d-b146-a48d229be428%40googlegroups.com >> >> <https://groups.google.com/d/msgid/tiddlywiki/a827b52a-100c-453d-b146-a48d229be428%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/tiddlywiki. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/4429901c-fc17-4536-afcb-1069dafe5ee8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
