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. For more options, visit https://groups.google.com/d/optout.
