IssueTracker

Problem you have encountered:
During a setup of a GCS backend bucket with a load balancer and CDN for use with Dynamic Compression, I found that if a file was already compressed with gzip it could be requested from GCS as "deflated". However, if a file was requested that was compressed with brotli, it would not be deflated and is still returned to the client.

Behavior 1 - Using "gsutil cp -Z" to upload a file to GCS applies gzip compression. Pulling that file down from GCS - or from the load balancer IP shows the response is gunzipped for the client.

$ curl -s -v -H 'Accept-Encoding: deflate' https://storage.googleapis.com/<bucket>/<gzip-file.json>
< HTTP/2 200
< content-type: application/json
< x-goog-stored-content-encoding: gzip
< x-guploader-response-body-transformations: gunzipped
< warning: 214 UploadServer gunzipped

Behavior 2 - Using "brotli -Z" locally to compress and "gsutil cp" to upload a file. (Double checked metadata is correct with "br" in encoding) and ensure in a browser with support for brotli(chrome) this works as expected . However, if we curl using the deflate method, we still receive a brotli file. (Fails to write to output but can be piped to "brotli -d")

$ curl -s -v -H 'Accept-Encoding: deflate' https://storage.googleapis.com/<bucket>/<brotli-file.json>
< HTTP/2 200
< content-type: application/json
< content-encoding: br
< x-goog-stored-content-encoding: br
* Failure writing output to destination
 

What you expected to happen:
The response should either deflate or warn since the client is announcing with "Accept-Encoding" that it can only understand non-compressed data.


Other notes: This was tested with a JSON file size of 296KB (compresses down to ~20KB)