GAE flex env stripping custom ETag HTTP response header when resource is gzip transpiled?

[Christopher Russell]

I've got a custom Node.js server application deployed on Google Application Engine (flex environment) that sets the 'ETag' HTTP 1.1 response header for specific resource requests using a custom algorithm. This works well and provides me with very granular control of resource caching. However, in cases where my response is transparently transpiled (e.g. gzip compressed) it appears that Google App Engine is stripping off my ETag header and throwing it away.

For example, I have a 1 MB bundle of JavaScript that _should_ be downloaded _once_ on first run of a newly-deployed version of the application. The actual server response sets the ETag HTTP response header with a unique digest hash of the file's contents and Content-Type set to "utf8" and Content-Encoding set to "application/json". Given Content-Type and Content-Encoding I believe GAE concludes that the response can and should be gzip'd (my user agent sends HTTP request header Accept-Encoding gzip, deflate, br). And, upon receipt of the gzip'd JavaScript, the user agent decompresses and of course I'm dealing with the original JavaScript string in the browser. So this works. BUT... the user agent never ever receives the ETag header. And, so never sends an If-None-Match request header. So the file isn't cached as expected and must be downloaded again and again and again.

I can't think of any good reason why ETag (or any other cache-related response headers) should be altered at all GAE in this case where the transpilation is intended to be wholly encapsulated. Do you guys agree this is a bug?

Thanks, Chris

[Tiago (Google Cloud Platform Support)]

Hello Christopher, 

I can see this is a duplicate of a Public Issue Tracker post which you recently submitted. Please follow up any further posts related to this matter to that more active thread.