Further on the complexity of ETag and why Apache (and generic web servers) should not send an updated ETag in response to a PUT:
https://tools.ietf.org/id/draft-reschke-http-etag-on-write-09.html On Thursday, September 14, 2017 at 3:23:30 PM UTC-4, Lost Admin wrote: > > 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]> 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]. >>> 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/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/e0847c74-3200-4c68-9257-f2ac1983ff3c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
