|« 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:
Do not configure your origin server to request client authentication because CloudFront has no way to forward credentials from a viewer to your origin. You can configure CloudFront to forward requests to your origin using either HTTP or HTTPS; for more information, see How to Require HTTPS for Communication Between Viewers, CloudFront, and Your Origin.
For web 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 (Expiration).
CloudFront forwards requests that have the
Accept-Encoding field values
"gzip". For more information, see Serving Compressed Files.
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 or both 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).
You can configure CloudFront to forward cookies to your origin. For more information, see How CloudFront Forwards, Caches, and Logs Cookies.
CloudFront forwards HTTPS requests to the origin server using the SSLv3 or TLSv1 protocols and the AES128-SHA1 or RC4-MD5 ciphers. If your origin server does not support either the AES128-SHA1 or RC4-MD5 ciphers, CloudFront cannot establish an SSL connection to your origin.
When establishing an HTTPS connection to the origin, CloudFront adds a Server Name Indication (SNI) extension and includes the value of the applicable Origin Domain Name for your distribution. For more information about SNI, see Section 3.1 of RFC 4366, Transport Layer Security (TLS) Extensions.
If you configure CloudFront to process all of the HTTP methods that it supports, CloudFront accepts the following requests from users and forwards them to your custom origin:
CloudFront caches responses to
HEAD requests, and does not cache responses to
requests that use the other methods.
For information about configuring whether your custom origin processes these methods, see the documentation for your origin.
If you configure CloudFront to accept and forward to your origin all of the HTTP methods that CloudFront supports,
configure your origin server to handle all methods. For example, if you configure CloudFront to accept and forward these
methods because you want to use
POST, you must configure your origin server to handle
appropriately so users can't delete resources that you don't want them to. For more information, see the documentation
for your HTTP server.
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.
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.
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.
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.
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.
CloudFront removes hop-by-hop header fields such as the
before forwarding requests to your origin.
CloudFront adds a
User-Agent header with the following value before it forwards a request to your origin:
User-Agent = Amazon CloudFront
CloudFront adds this header regardless of whether the request from the viewer included a
If the request from the viewer includes a
User-Agent header, CloudFront removes it.
For information about how CloudFront processes responses from custom origin servers, see the applicable topic:
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
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.
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 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.
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.
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 either serves the expired version of the object or serves a custom error page.
For more information, see How CloudFront Processes and Caches HTTP 4xx and 5xx Status Codes.
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.
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.
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.