|« PreviousNext »|
|Did this page help you? Yes | No | Tell us about it...|
For information about how CloudFront processes viewer 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 the client IP address to your origin in the
X-Forwarded-For request header.
X-Forwarded-For request header looks like this:
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:
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.
CloudFront removes or updates the following header fields before forwarding requests to your origin:
Accept-Encoding: If the value contains
gzip, CloudFront forwards
Accept-Encoding: gzip to your origin. If the value does not contain
Accept-Encoding header field before forwarding the request to your origin.
HEAD requests: CloudFront removes the
header field before forwarding the request to your origin.
CloudFront does not remove the header field before forwarding the request to your origin.
Connection: CloudFront replaces this header with
Connection: Keep-Alive before forwarding
the request to your origin.
Cookie: If you configure CloudFront to forward cookies, it will forward the
header field to your origin. If you don't, CloudFront removes the
Cookie header field.
For more information, see How CloudFront Forwards, Caches, and Logs Cookies.
Host: CloudFront sets the value to the domain name of the origin that is associated with the
HEAD requests: CloudFront removes the header field before
forwarding the request to your origin.
If the value is
Transfer-Encoding: chunked, CloudFront does not remove the header field before
forwarding the request to your origin. For any other value, CloudFront does remove the header field before
forwarding the request to your origin.
User-Agent: CloudFront replaces the value of this header field with
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 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 viewers 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.1.
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 viewer 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 viewer request.
If you specify Match Viewer, CloudFront forwards requests to the origin server using the protocol in the viewer request. Note that CloudFront caches the object only once even if viewers make requests using both HTTP and HTTPS protocols.
If the viewer 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.
When CloudFront requests data from your origin, if the origin 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.
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 viewers 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.
Transfer-Encoding: Chunked: CloudFront returns the object to the viewer as it gets the object from your origin. However, if the chunked response is not complete, CloudFront does not 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.
CloudFront removes or updates the following header fields before forwarding the response from your origin to the viewer:
Set-Cookie: If you configure CloudFront to forward cookies, it will forward the
header field to clients. For more information, see How CloudFront Forwards, Caches, and Logs Cookies.
Transfer-Encoding: If your origin returns this header field, CloudFront sets the value to
chunked before returning the response to the viewer.
Via: Regardless of whether your origin returns this header field to CloudFront, CloudFront sets the value to:
before returning the response to the viewer. For example:
Via: 1.1 1026589cc7887e7a0dc7827b4example.cloudfront.net (CloudFront)
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.
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 a viewer 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 viewer.
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 viewer follows the redirect to the new URL, the viewer 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 viewer 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 viewer. 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 CloudFront returns the object to the client as the object is received
at the edge location, and caches the object in chunked format for subsequent requests.
We recommend that you use chunked encoding if the content length of your response cannot be predetermined. For more information, see Dropped TCP Connections.