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
Related
I have my google bucket connect with a load balancer and CDN enabled in google cloud, but I really don't get how google CDN working for static file, checking in the log viewer i can see the "statusDetails: response_from_cache" and "cacheHit: true" so i can say that the CDN is working properly.
Trying to issue a request for the image in my google CDN bucket from a computer located in Europe, the file return from the frontend IP address of my load balancer. Also the same IP address served my image if i make the request from a computer located in Asia.
So the same IP address was used for serving my static image ignore the location where the request coming from, checking the log viewer again, i can see that both of the request has claimed to go through google CDN, again google log viewer tell me that CDN working properly.
i think that the CDN should serve the file from the nearest server to the end-users, what is the point for using google CDN if the file always served from only 1 single IP address for all user over the world?
I have a free account of cloudflare, once i configure my DNS, the image file go through cloudflare network and if i do the test as above, i will see my static image file returned from multiple IP address which is nearest to my end-users.
Could somebody help me to understand what is the purpose for using google CDN in this case ? did i miss something in the configuration process for google CDN?
Thanks a lot in advance.
Google Cloud CDN uses Google's global edge network to serve content
closer to users and it leverages Google Cloud global external HTTP(S)
load balancers to provide routing, health checking, and Anycast IP
support. The HTTP(S) load balancing configuration specifies the
frontend IP addresses and ports on which Cloud CDN receives requests
and the backends that originate responses to those requests.
Google CDN has a special feature of ‘single anycast IP for the whole
network’ letting all contents served through the load balancer
frontend IP resulting in low latency. So rather than having one load
balancer per region, you can simplify your architecture and have
every instance behind a single global load balancer. Also it has a
feature of HTTP/2 which supports the latest HTTP protocol for faster
performance. For additional information, you can check here.
Cloud CDN reduces latency by serving assets directly at Google's
network edge. To know more about the caching using Cloud CDN, refer
to this caching-overview docs.
I have a static web site hosted on blob storage in Azure. I create an Azure CDN profile using Verizon standard account. I need to forward http requests to https automatically. I see a bunch of articles showing how ot do this with the rules engine but I cant seem to access it on my endpoint.
I cannot link an existing CDN that we use for the streaming endpoint. Should I be able to do this? I can only enable the default endpoint which creates a CDN profile called AzureMediaStreamingPlatformCdnProfile-StandardVerizon. Is it possible to link the streaming endpoint to an existing CDN?
From the Azure Media Services UI or API you can enable Azure CDN and use an existing Azure CDN profile or create a new CDN profile. A CDN profile represents a specific Azure CDN SKU and specific CDN provider (e.g. Verizon). Azure Media Services then handles the creation/deletion of the Azure CDN endpoint - which represents the CDN configuration. Azure Media Services API / UI does not allow one to select an existing CDN endpoint to be used with a streaming endpoint. The use of an existing CDN endpoint is only possible by using the Azure CDN API/UI to set the origin for the CDN endpoint to point to the streaming endpoint hostname. There are the following downsides to this approach - 1) You will need to use the CDN endpoint hostname (e.g. xxxxx.azureedge.net) to make use of the CDN 2) You will see data transfer charges for CDN cache fill traffic - i.e. traffic from the streaming endpoint to individual CDN POPs. This is typically a small % of your overall charges assuming you have a high cache-hit ratio (e.g. +90%) for content on the CDN.
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/
According to this post from 2014, https is not available to static sites on google cloud engine: https://stackoverflow.com/a/22767544/46799
Is this still the case? If so, are there any plans add this functionality?
My site is hosted on GCS and I have a cname entry which maps my url to a bucket on GCS. I need to start providing access to the site through https now, am I out of luck?
This is still the case, sorry. You can access GCS via HTTPS, but not via CNAME redirects.