I was looking through the Apache (which is a bit unfair) and www.webdav.org sites. I inferred a lot of what I think I understand.
>From what I can tell, there is no solid solution for data locking with WebDAV itself but there are some options available: WebDAV does have a built-in locking mechanism. Apache does support it but you have to turn it on. I haven't researched this one very far beyond reading about it's existence. The client would need to send a lock request (I haven't figured out how that is done yet) before (or during?) the GET request. Then use some reference to that with the PUT request. After that, as I understand it, the calling application would need to request a new lock after the PUT to continue editing (although that might actually be a misunderstanding on my part). Sorry, I can't find the reference to this now. For hard locks WebDAV Locks, the most coherent explantion I found is http://www.webdav.org/mod_dav/install.html#apache (part way down, beginning with Enabling DAV). Apache support two methods of "lazy updates". A lazy update is where the application doesn't actually request a lock. Instead the requesting application sends a "update based on some earlier version based on some value" and if the file hasn't been changed since that value was current, then the update happens, otherwise you get the 412. The two choices (for Apache) that I've found are: ETag and If-Match, which we currently only sort-of use right (based on how Apache behaves). I don't have a good clear single source of information. I read a bunch of blogs from programmers complaining about it (not specifically related to WebDAV) and a variety of Apache docs on cache control. If-Modified-Since header, which is based on the timestamp of the GET request. I stumbled across this one in a blog post but now I can't find it. Both of the ETag/If-Match and If-Modified-Since are actually cache control mechanisms. Sorry for my crappy references. In my personal opinion, I do think that ETag (or If-Modified-Since) is the way to go but we need to figure out a way to either get one back as a response to a PUT request (I've been trying to figure this out but so far have failed) or to figure out a way to do a follow-up GET request to reload the file from the WebDAV server after saving. If you look at the series of screenshots I created (https://wiki.suntrap.ca/davsaver.html), you will note that although Lighttpd doesn't send a 412 with the second PUT request, the ETag/If-Match is dropped in the 2nd PUT request. I *think* something has happened to remove all file locking protections after the first PUT. I haven't had time to set-up a working IIS test environment or I would have that sequence set-up too. 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 <thelos...@gmail.com > <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 tiddlywiki+...@googlegroups.com <javascript:>. >> To post to this group, send email to tiddl...@googlegroups.com >> <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 tiddlywiki+unsubscr...@googlegroups.com. To post to this group, send email to tiddlywiki@googlegroups.com. 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/4d3e7efd-1b67-489b-906b-d07078bb18a4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
