6

My company is thinking of moving from AWS to GCP. One of the feature we want to support from CloudCDN is brotli encoding. We have a techstack that will bundle our javascript into 3 files:

chunk.js
chunk.js.gz
chunk.js.br

If CloudCDN receives client request headers Accept-Encoding: br, gzip is CloudCDN smart enough to serve up Brotli file? Moreover, will it be cached? If not, are there any other approaches in achieving this in CloudCDN.

AWS Cloudfront only offers this feature with the use of 2 lamdbas. Which I think is a bad idea.

Armeen Moon
  • 18,061
  • 35
  • 120
  • 233

2 Answers2

13

Yes, Cloud CDN can cache all 3 representations and serve the correct one based on the client's Accept-Encoding header so long as the response from your origin server includes a Vary: Accept-Encoding header. There's more information at https://cloud.google.com/cdn/docs/caching#vary_headers.

Update:

I didn't realize you were using a Cloud Storage bucket as the origin. Unfortunately, neither Cloud CDN nor Cloud Storage have functionality that will rewrite client requests for /chunk.js to /chunk.js.br based on whether the client supports Brotli. I agree that would useful, so I filed an internal feature request.

When an origin server such as nginx is configured to select the appropriate file, Cloud CDN needs to go back to the origin server only on a cache miss. So long as the origin server's responses contain a Vary: Accept-Encoding header, Cloud CDN can serve cache hits directly from the edge by comparing the client's Accept-Encoding request header with the Accept-Encoding value specified when the response was cached. Clients that specify Accept-Encoding: br, gzip will be served from one cache entry while clients that specify Accept-Encoding: gzip will be served from another.

elving
  • 1,441
  • 8
  • 7
  • Just to be clear, I want the client to request chunk.js and receive chunk.js.br. Is the filename switch purely based off of convention? How does CloudCDN know to rewrite the filename/serve chunk.js.br from the requested chunk.js. – Armeen Moon Mar 10 '19 at 15:00
  • Sorry, I misunderstood your question. Cloud CDN will not rewrite the filename in the client request. The way this is normally done is the origin server chooses which file to serve (e.g. via nginx config) based on the Accept-Encoding request header and includes a Vary: Accept-Encoding response header to let the CDN know. – elving Mar 11 '19 at 22:20
  • Thanks so much for helping @elving. Shouldn't the CloudCDN just kind of point to a Google Cloud Storage bucket and the client should be served a file from the edge? By making a round trip to origin/nginx, it would seem to defeat the purpose of using CloudCDN(edge). Does CloudCDN distribute the web server/origin/nginx on the edge? If this is the case that sounds great, if not I'm still not fully understanding how this can all work. Sorry if I'm mangling verbiage – Armeen Moon Mar 11 '19 at 23:40
  • 4
    Has there been any progression on that internal feature request? I've found services like render.com offering this service out of the box by default – Armeen Moon Mar 03 '20 at 20:51
  • 1
    @elving Thanks for your answer but do you know if there has been any progression on that internal feature request ? – Paul Souteyrat Jul 06 '20 at 15:01
  • @elving was this resolved, we are using a GCS bucket backed CDN and it's not using brottle compression. – Sharvanath Sep 08 '22 at 22:37
0

CloudFront now supports Brotli compression natively. If you're using S3 as your origin (or any origin that returns uncompressed content), CloudFront can automatically compress at the edge using Brotli or Gzip. You don't need to create three versions of the file or use Lambda@Edge.

https://aws.amazon.com/about-aws/whats-new/2020/09/cloudfront-brotli-compression/

Cristian
  • 1,051
  • 7
  • 10