Google CDN bug with gzip compression

[Stevo Novkovski]

I`m not sure but i think Google CDN is not serving gzipped content on requests when requests send "Accept-Encoding:gzip" header.

Here is the output of CDN logs for same file:

As we can see from the image, this same cache-able file is served near 100% without gzip and few request are served with gziped. Both gzipped and not gzipped requests have cachehit : true.

Prove:

1. Google Chrome Request to CDN url: -> does not return gzipped content.

2. Google Chrome Request to Origin Server for same file. -> return gzipped content

3. Testing with webpagetest.org with CDN enabled.

4. Turning off CDN, test with webpagetest.org 

Maybe i`m missing something, but from my experience and acording to google cdn documentation, this request should be served with gzip compression.

[Carlos (Cloud Platform Support)]

Hi Stevo,

It is documented that Could CDN does not compress or decompress responses, instead that function is taken over by the backend service. 

If you are using a Cloud Bucket in your architecture you might want to have a look at this article. 

[Stevo Novkovski]

I use Litespeed web server as backend and Litespeed server gzip any response that have "Accept-Encoding:gzip".

As you can see from google logs, load balancer already have cached gzipped and non-gzipped response of same file, but delivering non-response in near 100% no matter if request have "Accept-Encoding:gzip".

And the things to be more confusing, today everything works fine.

Just check how today everything works:

1. http://prntscr.com/dr6dci  age: 32 hours -> works

2. http://prntscr.com/dr6dva age: 2 hours -> works

3. http://prntscr.com/dr6e4z -> everything is gzipped

4. http://prntscr.com/dr6exe -> CDN logs shows almost 100% gzipped response.

I`m pretty sure it was temporary cdn bug. However, lets count as fixed now until next similar issue.

[Carlos (Cloud Platform Support)]

I am glad the issue was transient, hopefully it will not recurred but let us keep an eye on it.