I finally found something that properly talks about Etags. You can infer why we don't get an ETag header in the response to a PUT (for both Apache and IIS). https://stackoverflow.com/questions/42246577/why-responses-to-put-requests-must-not-provide-an-etag
You can skip going to the link if you want to. It is asking for an explanation of when to send an ETag or not and I think we can use what it quotes to get the understanding. *An origin server MUST NOT send a validator header field* (Section 7.2 <https://tools.ietf.org/html/rfc7231#section-7.2>), such as an ETag or Last-Modified field, in a successful response to PUT unless the request's representation data was saved without any transformation applied to the body (i.e., the resource's new representation data is identical to the representation data received in the PUT request) and the validator field value reflects the new representation. This requirement allows a user agent to know when the representation body it has in memory remains current as a result of the PUT, thus not in need of being retrieved again from the origin server, and that *the new validator(s) received in the response can be used for future conditional requests* in order to prevent accidental overwrites (Section 5.2 <https://tools.ietf.org/html/rfc7231#section-5.2>). Apache (and IIS) allow for the server to be configured such that you can add a custom processor to specific HTTP actions (like PUT) that are completely independent of WebDAV (I forget how but I did one for a post call once because we didn't have source and needed to re-mangle some of the user input). This means that the Apache web server doesn't know for sure that what you send in the PUT through WebDAV will be what it picks up on the next GET. So, can't send and updated ETag. I imagine the same goes for IIS. Lighttpd doesn't appear to honor etag and If-Match headers so Lighttpd is broken. Nginx (I've been told) has a very primitive webdav module so is also not suitable for this discussion. 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/3206b23b-d4e5-4fe3-8984-70b449b7218c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
