|« PreviousNext »|
|Did this page help you? Yes | No | Tell us about it...|
For information about how CloudFront processes end-user requests and forwards the requests to your custom origin, see the applicable topic:
CloudFront accepts only
HEAD requests from end users.
You can configure whether CloudFront forwards query string parameters to your origin. For more information, see How CloudFront Forwards, Caches, and Logs Query String Parameters.
You can configure CloudFront to forward cookies to your origin. For more information, see How CloudFront Forwards, Caches, and Logs Cookies.
CloudFront forwards requests to your custom origin using HTTP/1.0, but supports most of the HTTP 1.1 specification.
To enhance performance, we recommend that you include the
Keep-Alive header in end-user requests.
CloudFront forwards HTTPS requests to the origin server using the SSLv3 or TLSv1 protocols and the AES128-SHA1 or RC4-MD5 ciphers.
CloudFront forwards HTTP or HTTPS requests to the origin server based on the following:
The protocol of the request that the end user sends to CloudFront, either HTTP or HTTPS.
The value of the Origin Protocol Policy field in the CloudFront console or, if you're using
the CloudFront API, the
OriginProtocolPolicy element in the
DistributionConfig complex type.
In the CloudFront console, the options are HTTP Only and Match Viewer.
If you specify HTTP Only, CloudFront forwards requests to the origin server using only the HTTP protocol, regardless of the protocol in the end-user request.
If you specify Match Viewer, CloudFront forwards requests to the origin server using the protocol in the end-user request. Note that CloudFront caches the object only once even if viewers make requests using both HTTP and HTTPS protocols.
If the end-user request uses the HTTPS protocol, and if the origin server returns an invalid certificate or a self-signed certificate, CloudFront drops the TCP connection.
If you aren't sure which protocol to use, we recommend that you specify HTTP only.
For information about how to update a distribution using the CloudFront console, see Listing, Viewing, and Updating CloudFront Distributions. For information about how to update a distribution using the CloudFront API, go to PUT Distribution Config in the Amazon CloudFront API Reference.
Do not configure your origin server to request client authentication. When CloudFront forwards an end-user request to your origin server over HTTPS, CloudFront does not present a certificate.
CloudFront removes hop-by-hop header fields such as the
before forwarding requests to your origin.
The IP address that CloudFront forwards to the origin server is the IP addresses of a CloudFront server, not the IP address of the end user's computer.
CloudFront forwards requests that have the
Accept-Encoding field values
"gzip, deflate". CloudFront accepts
and reorders the values to
For more information, see Serving Compressed Files.
For download distributions, to control how long your objects stay in a CloudFront cache before CloudFront forwards another request to your origin, you can:
Configure your origin to add a
Cache-Control or an
header field to each object.
Specify a value for Minimum TTL in CloudFront cache behaviors.
Use the default value of 24 hours.
For more information, see Specifying How Long Objects Stay in a CloudFront Edge Cache (Object Expiration).
When CloudFront receives a request for an object that has expired from an edge cache, it forwards the request to the
origin either to get the latest version of the object or to get confirmation from the origin that the CloudFront edge cache
already has the latest version. Typically, when the origin last sent the object to CloudFront, it included an
LastModified value, or both values in the response. In the new request that CloudFront forwards to the
origin, CloudFront adds one of the following:
If-None-Match header that contains the
for the expired version of the object.
If-Modified-Since header that contains the
for the expired version of the object.
The origin 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).
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.
For information about how CloudFront processes responses from custom origin servers, see the applicable topic:
The maximum size of a response body that CloudFront will return to the end user is 20 GB. This includes
chunked transfer responses that don't specify the
Content-Length header value.
Ensure that the origin server sets valid and accurate values for the
Last-Modified header fields.
If requests from end users include the
If-None-Match request header fields,
ETag response header field. If you do not specify an
ETag value, CloudFront
The only acceptable value for the
Vary header is
CloudFront ignores other values.
If you enable cookies for a cache behavior, and if the origin returns cookies with an object, CloudFront caches both the object and the cookies. Note that this reduces cacheability for an object. For more information, see How CloudFront Forwards, Caches, and Logs Cookies.
If you change the location of an object on the origin server, you can configure your web server to
redirect requests to the new location. After you configure the redirect, the first time an end user submits a request
for the object, CloudFront Front sends the request to the origin, and the origin responds with a redirect
302 Moved Temporarily). CloudFront caches the redirect and returns it to the end user.
CloudFront does not follow the redirect.
You can configure your web server to redirect requests to one of the following locations:
The new URL of the object on the origin server. When the end user follows the redirect to the new URL, the end user bypasses CloudFront and goes straight to the origin. As a result, we recommend that you not redirect requests to the new URL of the object on the origin.
The new CloudFront URL for the object. When the end user submits the request that contains the new CloudFront URL, CloudFront gets the object from the new location on your origin, caches it at the edge location, and returns the object to the end user. Subsequent requests for the object will be served by the edge location. This avoids the latency and load associated with viewers requesting the object from the origin. However, every new request for the object will incur charges for two requests to CloudFront.
If your origin server is unavailable and CloudFront gets a request for an object that is in the edge cache
but that has expired (for example, because the period of time specified in the
directive has passed), CloudFront continues to serve the expired version of the object. For more information about
object expiration, see Specifying How Long Objects Stay in a CloudFront Edge Cache (Object Expiration).
In some cases, an object that is seldom requested is evicted and is no longer available in the edge cache. CloudFront can't serve an object that has been evicted.
CloudFront supports only the
chunked value of the
Transfer-Encoding header. If your origin returns
Transfer-Encoding: chunked, CloudFront assembles the chunks into a monolithic object as they're received
at an edge location, returns the object to the client, and caches the object for subsequent requests. In addition,
CloudFront calculates a
Content-Length header and returns it in response to subsequent client requests.
We recommend that you not use chunked transfer encoding. If a chunk is delayed (by a firewall, for example), CloudFront has no way to know whether it already has the last chunk in an object, and may close the connection and cache a partial object. For more information, see Dropped TCP Connections.
If the TCP connection between CloudFront and your origin drops while your origin is returning an object to CloudFront, CloudFront behavior
depends on whether your origin included a
Content-Length header in the response:
Content-Length header: CloudFront returns the object to the viewer as it
gets the object from your origin. However, if the value of the
Content-Length header doesn't match
the size of the object, CloudFront doesn't cache the object.
No Content-Length header: CloudFront returns the object to the viewer and
caches it, but the object may not be complete. Without a
Content-Length header, CloudFront cannot
determine whether the TCP connection was dropped accidentally or on purpose.
We recommend that you configure your HTTP server to add a
Content-Length header to prevent CloudFront from
caching partial objects.
In general, if your custom origin server responds to a CloudFront request with any of the following status codes, CloudFront caches the code for five minutes regardless of the minimum TTL setting for the applicable cache behavior. In addition, CloudFront writes the results to the access logs.
If CloudFront already has an expired version of the requested object in the edge cache, it serves the expired object instead.
Method Not Allowed
Request-URI Too Large
Internal Service Error