Request and Response Behavior, and Supported HTTP Status Codes for Custom Origins

CloudFront accepts only GET and 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:

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 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 Authorization and Connection fields 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 "identity" and "gzip, deflate". CloudFront accepts "deflate, gzip" and reorders the values to "gzip, deflate".

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:

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 ETag value, a LastModified value, or both values in the response. In the new request that CloudFront forwards to the origin, CloudFront adds one of the following:

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.

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.

The only acceptable value for the Vary header is Accept-Encoding. 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 (for example, 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:

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 Cache-Control max-age 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:

We recommend that you configure your HTTP server to add a Content-Length header to prevent CloudFront from caching partial objects.