ETags not verified correctly when application sits behind apache proxy with DeflateAlterETag set to AddSuffix [DATAREST-1133]

Patrik Mihalcin opened DATAREST-1133 and commented

Given I have Spring Data REST based app deployed to Weblogic which sits behind Apache Proxy.

When I make request to item resource, I can see ETag:"0-gzip" in response headers (instead of typical ETag:"0").

-gzip was appended by apache proxy because of enabled mod_deflate (where DeflateAlterETag is set to AddSuffix) https://httpd.apache.org/docs/trunk/mod/mod_deflate.html#deflatealteretag

After some searching, Apache appends -gzip for a reason (so that proxies can cache a gzipped and non-gzipped version depending on if the client supports it or not)

Should the application which uses Spring Data REST somehow cater for that?

Why ETags are preferred way to do conditional updates in Spring Data REST? Can't we rely on Cache-Control and Last-Modified?

This article describes the pain of ETags:
https://fullstackhack.wordpress.com/2014/12/10/the-pain-of-etags-mod_deflate-apache-2-4-and-tomcat-7/

Thanks for the explanation

1 votes, 2 watchers