|« PreviousNext »|
|Did this page help you? Yes | No | Tell us about it...|
Amazon CloudFront can serve both compressed and uncompressed files from an origin server. CloudFront relies on the origin server either to compress the files or to have compressed and uncompressed versions of files available; CloudFront does not perform the compression on behalf of the origin server. With some qualifications, CloudFront can also serve compressed content from Amazon S3. For more information, see Choosing the File Types to Compress.
CloudFront can only serve compressed data if the viewer (for example, a web browser or media player) requests
compressed content by including
Accept-Encoding: gzip in the request header. The content must be compressed
using gzip; other compression algorithms are not supported. If the request header includes additional content
encodings, for example,
sdch, CloudFront removes them before forwarding the request
to the origin server. If
gzip is missing from the
CloudFront serves only the uncompressed version of the file. For more information about the
field, see "Section 14.3 Accept Encoding" in Hypertext Transfer Protocol -- HTTP/1.1 at
For more information, see the following topics:
Here's how CloudFront commonly serves compressed content from a custom origin to a web application:
You configure your web server to compress selected file types. For more information, see Choosing the File Types to Compress.
You create a CloudFront distribution.
You program your web application to access files using CloudFront URLs.
A user accesses your application in a web browser.
CloudFront directs web requests to the edge location that has the lowest latency for the user, which may or may not be the geographically closest edge location.
At the edge location, CloudFront checks the cache for the object referenced in each request.
If the browser included
Accept-Encoding: gzip in the request header, CloudFront
checks for a compressed version of the file. If not, CloudFront checks for an uncompressed version.
If the file is in the cache, CloudFront returns the file to the web browser. If the file is not in the cache:
CloudFront forwards the request to the origin server.
If the request is for a type of file that you want to serve compressed (see Step 1), the web server compresses the file.
The web server returns the file (compressed or uncompressed, as applicable) to CloudFront.
CloudFront adds the file to the cache and serves the file to the user's browser.
By default, IIS does not serve compressed content for requests that come through proxy
servers such as CloudFront. If you're using IIS and if you configured IIS to compress content by using the
httpCompression element, change the values of the
noCompressionForProxies attributes to false. For example, for IIS version 7 and later, you might use
the following commands:
Before you run these commands, see the IIS documentation for
appcmd.exe to verify that the
syntax hasn't changed for your version of IIS.
%systemroot%\system32\inetsrv\appcmd.exe set config -section:system.webServer/httpCompression /noCompressionForHttp10:false /commit:apphost %systemroot%\system32\inetsrv\appcmd.exe set config -section:system.webServer/httpCompression /noCompressionForProxies:false /commit:apphost
In addition, if you have compressed objects that are requested less frequently than every few seconds,
you may have to change the values of
For more information, refer to the IIS documentation on the Microsoft website.
Some versions of NGINX require that you customize NGINX settings when you're using CloudFront to serve compressed files.
In the documentation for your version of NGINX, see the documentation for the
more information about the following settings:
gzip_http_version: CloudFront sends requests in HTTP 1.0 format. In some versions of NGINX, the
default value for the
gzip_http_version setting is 1.1. If your version of NGINX includes this setting,
change the value to
gzip_proxied: When CloudFront forwards a request to the origin server,
it includes a
Via header. This causes NGINX to interpret the request as proxied and, by default,
NGINX disables compression for proxied requests. If your version of NGINX includes the
setting, change the value to
If you want to serve compressed files from Amazon S3:
Create two versions of each file, one compressed and one uncompressed. To ensure that the compressed and uncompressed versions of a file don't overwrite one another in the CloudFront cache, give each file a unique name, for example, welcome.js and welcome.js.gz.
Open the Amazon S3 console at https://console.aws.amazon.com/s3/.
Upload both versions to Amazon S3.
Content-Encoding header field for each
compressed file and set the field value to
For an example of how to add a
Content-Encoding header field using the AWS SDK for PHP,
see Upload an Object Using the AWS SDK for PHP in the
Amazon Simple Storage Service Developer Guide. Some third-party tools are also able to add this field.
To add a
Content-Encoding header field and set the field value using the Amazon S3 console, perform the following
In the Amazon S3 console, in the Buckets pane, click the name of the bucket that contains the compressed files.
At the top of the Objects and Folders pane, click Actions and, in the Actions list, click Properties.
In the Properties pane, click the Metadata tab.
In the Objects and Folders pane, click the name of a file for which you want to add a
Content-Encoding header field.
On the Metadata tab, click
Add More Metadata.
In the Key list, click
In the Value field, enter
Repeat Step 4d through 4h for the remaining compressed files.
When generating HTML that links to content in CloudFront (for example, using php, asp, or jsp),
evaluate whether the request from the viewer includes
in the request header. If so, rewrite the corresponding link to point to the compressed object name.