Client IP Addresses

If the X-Forwarded-For request header contains two or more IP addresses, the first one is always
the client IP address. The other addresses are for each successive proxy that passes along the request;
the last IP address is for the proxy that forwarded the request to CloudFront:

Conditional GETs

When CloudFront receives a request for an object that has expired from an edge cache, it forwards the request to the
Amazon S3 origin either to get the latest version of the object or to get confirmation from Amazon S3 that the CloudFront edge cache
already has the latest version. When Amazon S3 originally sent the object to CloudFront, it included an ETag value and a
LastModified value in the response. In the new request that CloudFront forwards to Amazon S3, CloudFront adds one or both
of the following:

An If-Match or If-None-Match header that contains the ETag value
for the expired version of the object.

An If-Modified-Since header that contains the LastModified value
for the expired version of the object.

Amazon S3 uses this information to determine whether the object has been updated and, therefore, whether to return
the entire object to CloudFront or to return only an HTTP 304 status code (not modified).

HTTP Methods

If you configure CloudFront to process all of the HTTP methods that it supports, CloudFront accepts the following requests from viewers
and forwards them to your Amazon S3 origin:

DELETE

GET

HEAD

OPTIONS

PATCH

POST

PUT

CloudFront always caches responses to GET and HEAD requests. You can also configure CloudFront
to cache responses to OPTIONS requests. CloudFront does not cache responses to requests that use the other methods.

If you configure CloudFront to accept and forward to Amazon S3 all of the HTTP methods that CloudFront supports,
you must create a CloudFront origin access identity to restrict access to your Amazon S3 content and grant the
origin access identity the applicable permissions. For example, if you configure CloudFront to accept and forward these methods
because you want to use PUT, you must configure Amazon S3 bucket policies or ACLs to handle DELETE
requests appropriately so viewers can't delete resources that you don't want them to. For more information, see
Using an Origin Access Identity to Restrict Access to Your Amazon S3 Content.

HTTP Request Headers that CloudFront Removes or Updates

CloudFront removes or updates the following header fields before forwarding requests to your Amazon S3 origin:

Accept

Accept-Charset

Accept-Encoding: If the value contains gzip, CloudFront forwards
Accept-Encoding: gzip to your Amazon S3 origin. If the value does not contain gzip, CloudFront
removes the Accept-Encoding header field before forwarding the request to your origin.

Accept-Language

Authorization:

GET and HEAD requests: CloudFront removes the Authorization
header field before forwarding the request to your origin.

OPTIONS requests: CloudFront removes the Authorization header field before
forwarding the request to your origin if you configure CloudFront to cache responses to OPTIONS requests.

CloudFront forwards the Authorization header field to your origin if you do not configure CloudFront to
cache responses to OPTIONS requests.

DELETE, PATCH, POST, and PUT requests:
CloudFront does not remove the header field before forwarding the request to your origin.

Host: CloudFront sets the value to the name of the Amazon S3 bucket that is associated with the requested object.

Proxy-Authorization

Referer

TE

Upgrade

User-Agent: CloudFront replaces the value of this header field with Amazon CloudFront.

Maximum Length of a Request and Maximum Length of a URL

The maximum length of a request, including the path, the query string (if any), and headers, is 20480 bytes.

CloudFront constructs a URL from the request. The maximum length of this URL is 8192 bytes.

If a request or a URL exceeds these limits, CloudFront drops the request.

OCSP Stapling

When a viewer submits an HTTPS request for an object, either CloudFront or the viewer needs to confirm with the
certificate authority (CA) that the SSL certificate for the domain has not been revoked. OCSP stapling speeds up
certificate validation by allowing CloudFront to validate the certificate and to cache the response from the CA, so the
client doesn't need to validate the certificate directly with the CA.

The performance improvement of OCSP stapling is more pronounced when CloudFront receives a lot of HTTPS requests
for objects in the same domain. Each server in a CloudFront edge location must submit a separate validation request. When CloudFront
receives a lot of HTTPS requests for the same domain, every server in the edge location soon has a response from the CA
that it can "staple" to a packet in the SSL handshake; when the viewer is satisfied that the certificate is valid,
CloudFront can serve the requested object. If your distribution doesn't get much traffic in a CloudFront edge location,
new requests are more likely to be directed to a server that hasn't validated the certificate with the CA yet.
In that case, the viewer separately performs the validation step and the CloudFront server serves the object.
That CloudFront server also submits a validation request to the CA, so the next time it receives a request that includes
the same domain name, it has a validation response from the CA.

Protocols

CloudFront forwards HTTP or HTTPS requests to the origin server based on the protocol of the viewer request,
either HTTP or HTTPS.

Important

If your Amazon S3 bucket is configured as a website endpoint, you cannot configure CloudFront to use HTTPS
to communicate with your origin because Amazon S3 doesn't support HTTPS connections in that configuration.

Request Timeout

The request timeout for CloudFront depends on the HTTP method:

GET and HEAD requests – If Amazon S3 doesn't respond within 30 seconds or
stops responding for 30 seconds, CloudFront drops the connection and makes two additional attempts to contact the origin.
If the origin doesn't reply during the third attempt, CloudFront doesn't try again until it receives another request for content
on the same origin.

DELETE, OPTIONS, PATCH, POST, and POST requests –
If Amazon S3 doesn't respond within 30 seconds, CloudFront drops the connection and doesn't try again to contact the origin.
The client can resubmit the request if necessary.

The request timeout cannot be changed.

How CloudFront Processes Responses from Your Amazon S3 Origin Server

Canceled Requests

If an object is not in the edge cache, and if a viewer terminates a session (for example, closes a browser)
after CloudFront gets the object from your origin but before it can deliver the requested object, CloudFront does not
cache the object in the edge location.

HTTP Response Headers that CloudFront Removes or Updates

CloudFront removes or updates the following header fields before forwarding the response from your Amazon S3 origin to the viewer:

Transfer-Encoding: If your Amazon S3 origin returns this header field, CloudFront sets the value to
chunked before returning the response to the viewer.

Upgrade

Vary

Via: CloudFront sets the value to:

Via: 1.1 alphanumeric-string.cloudfront.net (CloudFront)

before returning the response to the viewer. For example:

Via: 1.1 1026589cc7887e7a0dc7827b4example.cloudfront.net (CloudFront)

Maximum File Size

The maximum size of a response body that CloudFront will return to the viewer is 20 GB. This includes
chunked transfer responses that don't specify the Content-Length header value.

Redirects

You can configure an Amazon S3 bucket to redirect all requests to another host name; this can be another Amazon S3 bucket or an
HTTP server. If you configure a bucket to redirect all requests and if the bucket is the origin for a CloudFront distribution,
we recommend that you configure the bucket to redirect all requests to a CloudFront distribution using either the domain name
for the distribution (for example, d111111abcdef8.cloudfront.net) or an alternate domain name (a CNAME) that is associated
with a distribution (for example, example.com). Otherwise, viewer requests bypass CloudFront, and the objects are served directly
from the new origin.

Note

If you redirect requests to an alternate domain name, you must also update the DNS service for your domain by
adding a CNAME record. For more information, see Using Alternate Domain Names (CNAMEs).

Here's what happens when you configure a bucket to redirect all requests:

A viewer (for example, a browser) requests an object from CloudFront.

CloudFront forwards the request to the Amazon S3 bucket that is the origin for your distribution.

Amazon S3 returns an HTTP status code 301 (Moved Permanently) as well as the new location.

CloudFront caches the redirect status code and the new location, and returns the values to the viewer. CloudFront does not
follow the redirect to get the object from the new location.

The viewer sends another request for the object, but this time the viewer specifies the new location that it got from CloudFront:

If the Amazon S3 bucket is redirecting all requests to a CloudFront distribution, using either the domain name
for the distribution or an alternate domain name, CloudFront requests the object from the Amazon S3 bucket or the HTTP server
in the new location. When the new location returns the object, CloudFront returns it to the viewer and caches it in an
edge location.

If the Amazon S3 bucket is redirecting requests to another location, the second request bypasses CloudFront.
The Amazon S3 bucket or the HTTP server in the new location returns the object directly to the viewer, so the object
is never cached in a CloudFront edge cache.