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.
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.
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/
Related
My backend, in Rocket (Rust), does not have compression built in. So, it is dependent on the proxy to compress it. Though nginx ingress controller supports it, I thought whether the default one had it too as it has high availability.
If it does not have, then how should I setup?
UPDATE(2018-01-31): It looks like Cloud HTTP(S) Load Balancer supports GZIP. You just have to serve compressed content from your backend and the load balancer will pass it on.
However, NGINX is confused because of the Via header (it thinks proxies don't support GZIP, and on most cloud providers this is correct, but not Google). See this FAQ: https://cloud.google.com/cdn/docs/troubleshooting#compression-not-working
If you are using the nginx web server software, modify the nginx.conf
configuration file to enable compression. The location of this file
depends on where nginx is installed. In many Linux distributions, the
file is stored at /etc/nginx/nginx.conf. To allow nginx compression to
work with HTTP(S) load balancing, add the following two lines to the
http section of nginx.conf:
gzip_proxied any;
gzip_vary on;
I believe nginx does not compress requests via a proxy by default.
You can change its config to enable that:
gzip_proxied any;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
Source: https://blog.percy.io/tuning-nginx-behind-google-cloud-platform-http-s-load-balancer-305982ddb340
We are using IBM CDN and which is mapped to our IIS server. If the resource is getting fetched directly from the server, gzip compression is enabled. But if the same resource is fetched through CDN it is not compressed.
How can I enable gzip compression for IBM CDN resources?
First I think the IBM CDN you mentioned is the CDN service documented here IBM CDN Service
By default, the IBM CDN service will use gzip to compress the response if the content type is one if text/html*, text/css*, application/x-javascript*.
If you found the IBM CDN doesn't compress the content as your origin, then can you share the detailed request and response header from the origin and the CDN?
Bali
How do we enable gzip to reduce latency on both mobile and desktop users of static web resources?
You can upload Google Cloud Storage objects with a gzip Content Encoding, and they'll be served zipped to clients that send Accept-Encoding: gzip, which most browsers do.
See Transcoding of gzip-compressed files for more information.
I created an S3 bucket and enabled "Redirect all requests to another host name" under "Static Website Hosting".
This works and when I visit http://www.XXXX.com.s3-website-us-east-1.amazonaws.com, I am redirected to my end destination.
If however, I try to access the same URL over HTTPS: https://www.XXXX.com.s3-website-us-east-1.amazonaws.com, the connection times out.
Is it possible to specify an SSL certificate to use so that the redirect can handle HTTPS traffic?
With S3 by itself, no, it isn't possible. The web site endpoints don't speak SSL at all, and the REST endpoints don't handle redirects or allow any cert other than the *.s3(-region).amazonaws.com cert.
However, you can do it with CloudFront and S3 combined, if your clients support SNI.
Create a CloudFront distribution, configured with your hostname and SSL certificate, but don't use an "S3 Origin." Use a "custom origin" and that origin is your S3 web site endpoint hostname, with all requests forwarded to the origin using http (even though it's https on the front end).
If you are not familiar with CloudFront, this probably sounds a little convoluted, but I use it for exactly this purpose (among others).
Requests hit CloudFront, which allows you to use your own SSL cert... and then CloudFront forwards the request to S3, which returns the redirect, which CloudFront will cache and return to the requester (as well as to future requesters hitting the same CloudFront edge location).
The cost for this extra layer is negligible and you should not see any meaningful change in performance (if anything, there's potential for a slight speed improvement).
I have a webserver without content-coding (boa and not enough ressources). is there a possibility to put ziped javascript-file on the webserver and unzip it at the browser after downloading like content-coding?
In theory yes. You would need to add the Content-Encoding: deflate header to your http response.
You can not place a zip file created by a zip program on the server to be transferred, as it contains a header with the file structure before the deflate payload begins.
Also mind the differences between gzip and deflate. With gzip, similar is possible, too.