# Comportamiento de solicitudes y respuestas
En los siguientes temas se describe cómo CloudFront gestiona las solicitudes y las respuestas.
Puede obtener información sobre cómo CloudFront interactúa con Amazon S3 u orígenes personalizados, gestiona diversos métodos y encabezados HTTP, procesa códigos de estado y administra el almacenamiento en caché y las respuestas de error.
**Topics**
+ [Cómo procesa CloudFront las solicitudes HTTP y HTTPS](HTTPandHTTPSRequests.md)
+ [Comportamiento de solicitudes y respuestas para orígenes de Amazon S3](RequestAndResponseBehaviorS3Origin.md)
+ [Comportamiento de solicitudes y respuestas para orígenes personalizados](RequestAndResponseBehaviorCustomOrigin.md)
+ [Comportamiento de solicitudes y respuestas para grupos de origen](RequestAndResponseBehaviorOriginGroups.md)
+ [Añadido de encabezados personalizados a solicitudes de origen](add-origin-custom-headers.md)
+ [Cómo CloudFront procesa las solicitudes parciales de un objeto (rango GET)](RangeGETs.md)
+ [Cómo CloudFront procesa los códigos de estado HTTP 3xx desde el origen](http-3xx-status-codes.md)
+ [Procesamiento de CloudFront de los códigos de estado HTTP 4xx y 5xx desde el origen](HTTPStatusCodes.md)
+ [Generación de respuestas de error personalizadas](GeneratingCustomErrorResponses.md)
# Cómo procesa CloudFront las solicitudes HTTP y HTTPS
Para los orígenes de Amazon S3, CloudFront acepta de forma predeterminada solicitudes en protocolos HTTP y HTTPS para objetos de una distribución de CloudFront. A continuación, CloudFront reenvía las solicitudes al bucket de Amazon S3 utilizando el mismo protocolo en el que se hicieron las solicitudes.
En el caso de orígenes personalizados, al crear su distribución, puede especificar cómo CloudFront obtiene acceso a su origen: solo HTTP o con el mismo protocolo utilizado por el lector. Para obtener más información acerca de cómo CloudFront gestiona las solicitudes HTTP y HTTPS para orígenes personalizados, consulte [Protocolos](RequestAndResponseBehaviorCustomOrigin.md#RequestCustomProtocols).
Para obtener información acerca de cómo restringir la distribución para que los usuarios finales solo puedan obtener acceso a los objetos a través de HTTPS, consulte [Uso de HTTPS con CloudFront](using-https.md).
**nota**
El cargo por solicitudes HTTPS es superior al de solicitudes HTTP. Para obtener más información acerca de tarifas de facturación, consulte los [precios de CloudFront](https://aws.amazon.com/cloudfront/#pricing).
# Comportamiento de solicitudes y respuestas para orígenes de Amazon S3
Para entender cómo CloudFront procesa solicitudes y respuestas cuando se está utilizando Amazon S3 como origen, consulte las secciones siguientes:
**Topics**
+ [Cómo CloudFront procesa y reenvía solicitudes a su origen de Amazon S3](#RequestBehaviorS3Origin)
+ [Cómo procesa CloudFront las respuestas de su origen de Amazon S3](#ResponseBehaviorS3Origin)
## Cómo CloudFront procesa y reenvía solicitudes a su origen de Amazon S3
Obtenga información sobre cómo CloudFront procesa solicitudes de lectores y las reenvía a su origen de Amazon S3.
**Contents**
+ [Duración de almacenamiento en caché y TTL mínimo](#RequestS3Caching)
+ [Direcciones IP de clientes](#RequestS3IPAddresses)
+ [Solicitudes GET condicionales](#RequestS3ConditionalGETs)
+ [Cookies](#RequestS3Cookies)
+ [Compartir recursos entre orígenes (CORS)](#RequestS3-cors)
+ [Solicitudes GET que incluyen un cuerpo](#RequestS3-get-body)
+ [Métodos HTTP](#RequestS3HTTPMethods)
+ [Encabezados de solicitud HTTP que CloudFront elimina o actualiza](#request-s3-removed-headers)
+ [Longitud máxima de una solicitud y de una URL](#RequestS3MaxRequestStringLength)
+ [Asociación de OCSP](#request-s3-ocsp-stapling)
+ [Protocolos](#RequestS3Protocol)
+ [Cadenas de consulta](#RequestS3QueryStrings)
+ [Tiempo de espera e intentos de conexión de origen](#s3-origin-timeout-attempts)
+ [Tiempo de espera de respuesta de origen](#RequestS3RequestTimeout)
+ [Solicitudes simultáneas del mismo objeto (contracción de solicitudes)](#request-s3-traffic-spikes)
### Duración de almacenamiento en caché y TTL mínimo
Para controlar durante cuánto tiempo se mantienen los objetos en una caché de CloudFront antes de que CloudFront reenvíe otra solicitud al origen, puede:
+ Configure su origen para añadir un `Cache-Control` o un encabezado `Expires` para cada objeto.
+ Especificar un valor de TTL mínimo en comportamientos de la caché de CloudFront.
+ Utilice el valor de predeterminado de 24 horas.
Para obtener más información, consulte [Administración de cuánto tiempo se mantiene el contenido en una caché (vencimiento)](Expiration.md).
### Direcciones IP de clientes
Si un lector envía una solicitud a CloudFront y no incluye un encabezado de solicitud `X-Forwarded-For`, CloudFront obtiene la dirección IP del lector de la conexión TCP, agrega un encabezado `X-Forwarded-For` que incluya la dirección IP y reenvía la solicitud al origen. Por ejemplo, si CloudFront obtiene la dirección IP `192.0.2.2` de la conexión TCP, reenvía el siguiente encabezado al origen:
`X-Forwarded-For: 192.0.2.2`
Si un lector envía una solicitud a CloudFront e incluye un encabezado de solicitud `X-Forwarded-For`, CloudFront obtiene la dirección IP del lector de la conexión TCP, la agrega al final del encabezado `X-Forwarded-For` que incluya la dirección IP y reenvía la solicitud al origen. Por ejemplo, si la solicitud del lector incluye `X-Forwarded-For: 192.0.2.4,192.0.2.3` y CloudFront obtiene la dirección IP `192.0.2.2` de la conexión TCP, reenvía el siguiente encabezado al origen:
`X-Forwarded-For: 192.0.2.4,192.0.2.3,192.0.2.2`
**nota**
El encabezado `X-Forwarded-For` contiene direcciones IPv4 (como 192.0.2.44) e IPv6 (como 2001:0db8:85a3::8a2e:0370:7334).
### Solicitudes GET condicionales
Cuando CloudFront recibe una solicitud de un objeto que ha caducado en una caché perimetral, reenvía la solicitud al origen de Amazon S3 para obtener la última versión del objeto o para obtener la confirmación de Amazon S3 de que la caché perimetral de CloudFront ya dispone de la última versión. Cuando Amazon S3 envió el objeto originalmente a CloudFront, incluyó un valor `ETag` y un valor `LastModified` en la respuesta. En la nueva solicitud que CloudFront reenvía a Amazon S3, CloudFront agrega uno o ambos de los siguientes encabezados:
+ Un encabezado `If-Match` o `If-None-Match` que contenga el valor `ETag` para la versión caducada del objeto.
+ Un encabezado `If-Modified-Since` que contenga el valor `LastModified` para la versión caducada del objeto.
Amazon S3 utiliza esta información para determinar si el objeto se ha actualizado y, en consecuencia, si debe devolver todo el objeto a CloudFront o devolver solo un código de estado HTTP 304 (no modificado).
### Cookies
Amazon S3 no procesa cookies. Si configura un comportamiento de caché para reenviar las cookies a un origen de Amazon S3, CloudFront reenvía las cookies, pero Amazon S3 las ignora. Todas las solicitudes futuras del mismo objeto, independientemente si varía la cookie, se atienden desde el objeto existente en la caché.
### Compartir recursos entre orígenes (CORS)
Si desea que CloudFront respete la configuración de intercambio de recursos entre orígenes de Amazon S3, configure CloudFront para que reenvíe los encabezados seleccionados a Amazon S3. Para obtener más información, consulte [Almacenamiento en caché de contenido en función de encabezados de solicitud](header-caching.md).
### Solicitudes GET que incluyen un cuerpo
Si una solicitud `GET` del lector incluye un cuerpo, CloudFront devuelve un código de estado HTTP 403 (prohibido) al lector.
### Métodos HTTP
Si configura CloudFront para procesar todos los métodos de HTTP que admite, CloudFront acepta las siguientes solicitudes de los lectores y los reenvía al origen de Amazon S3:
+ `DELETE`
+ `GET`
+ `HEAD`
+ `OPTIONS`
+ `PATCH`
+ `POST`
+ `PUT`
CloudFront siempre almacena en caché las respuestas a las solicitudes `GET` y `HEAD`. También puede configurar CloudFront para almacenar en caché las respuestas a solicitudes `OPTIONS`. CloudFront no almacena en caché las respuestas a las solicitudes que utilizan los otros métodos.
Si desea utilizar cargas de multipartes para agregar objetos a un bucket de Amazon S3, debe agregar un control de acceso de origen (OAC) de CloudFront a su distribución y conceder al OAC los permisos necesarios. Para obtener más información, consulte [Restricción del acceso a un origen de Amazon S3](private-content-restricting-access-to-s3.md).
**importante**
Si configura CloudFront para que acepte y reenvíe a Amazon S3 todos los métodos HTTP que CloudFront admite, debe crear un OAC de CloudFront para restringir el acceso a su contenido de Amazon S3 y conceder al OAC los permisos necesarios. Por ejemplo, si configura CloudFront para que acepte y reenvíe estos métodos porque desea utilizar el método `PUT`, debe configurar las políticas de buckets de Amazon S3 para que se ocupen de las solicitudes de `DELETE` de forma adecuada, de modo que los lectores no puedan eliminar recursos que usted no desea. Para obtener más información, consulte [Restricción del acceso a un origen de Amazon S3](private-content-restricting-access-to-s3.md).
Para obtener más información acerca de las operaciones admitidas por Amazon S3, consulte la [documentación de Amazon S3](https://docs.aws.amazon.com/s3/index.html).
### Encabezados de solicitud HTTP que CloudFront elimina o actualiza
CloudFront elimina o actualiza algunos encabezado antes de reenviar solicitudes a su origen de Amazon S3. Para la mayoría de encabezados este comportamiento es el mismo que para orígenes personalizados. Para obtener una lista completa de encabezados de solicitudes HTTP y cómo los procesa CloudFront, consulte [Encabezados de solicitudes HTTP y comportamiento de CloudFront (personalizado y orígenes de Amazon S3)](RequestAndResponseBehaviorCustomOrigin.md#request-custom-headers-behavior).
### Longitud máxima de una solicitud y de una URL
La longitud máxima de una solicitud, incluida la ruta, la cadena de consulta (si procede) y los encabezados, es 20 480 bytes.
CloudFront crea una URL a partir de la solicitud. La longitud máxima de esta URL es de 8 192 bytes.
Si una solicitud o una URL supera la longitud máxima, CloudFront devuelve el código de estado HTTP 413 (entidad de solicitud demasiado grande), al lector y, a continuación, interrumpe la conexión TCP con el lector.
### Asociación de OCSP
Cuando un lector envía una solicitud de un objeto HTTPS, CloudFront o el lector deben confirmar con la autoridad de certificación (CA) que el certificado SSL del dominio no se ha revocado. La asociación de OCSP agiliza la validación de certificados al permitir a CloudFront validar el certificado y almacenar en caché la respuesta de la CA, por lo que el cliente no tiene por qué validar el certificado directamente con la CA.
La mejora en el rendimiento de la asociación de OCSP es más notoria cuando CloudFront recibe una gran cantidad de solicitudes de HTTPS de objetos en el mismo dominio. Cada servidor en una ubicación periférica de CloudFront debe enviar una solicitud de validación independiente. Cuando CloudFront recibe una gran cantidad de solicitudes HTTPS para el mismo dominio, cada servidor de la ubicación periférica obtiene pronto una respuesta de la CA que puede asociar a un paquete en el protocolo de enlace de SSL. Cuando el lector confirme que el certificado es válido, CloudFront puede entregar el objeto solicitado. Si la distribución no recibe mucho tráfico en una ubicación periférica de CloudFront, es más probable que las nuevas solicitudes se dirijan a un servidor que todavía no haya validado el certificado con la CA. En ese caso, el lector realiza el paso de validación por separado y el servidor de CloudFront ofrece el objeto. Este servidor de CloudFront también envía una solicitud de validación a la CA, por lo que la próxima vez que recibe una solicitud que incluye el mismo nombre de dominio, cuenta con una respuesta de validación de la CA.
### Protocolos
CloudFront reenvía las solicitudes de HTTP o HTTPS al servidor de origen en función del protocolo de la solicitud del lector, ya sea HTTP o HTTPS.
**importante**
Si su bucket de Amazon S3 se configura como un punto de enlace de sitio web, no puede configurar CloudFront para usar HTTPS para comunicarse con su origen porque Amazon S3 no admite conexiones HTTPS en dicha configuración.
### Cadenas de consulta
Puede configurar si CloudFront reenvía parámetros de cadenas de consulta a su origen Amazon S3. Para obtener más información, consulte [Almacenamiento en caché de contenido en función de parámetros de cadenas de consulta](QueryStringParameters.md).
### Tiempo de espera e intentos de conexión de origen
*Origin connection timeout (Tiempo de espera de conexión de origen)* es el número de segundos que CloudFront espera al intentar establecer una conexión con el origen.
*Origin connection attempts (Intentos de conexión de origen)* es el número de veces que CloudFront intenta conectarse al origen.
Juntos, estos parámetros determinan cuánto tiempo intenta CloudFront conectarse al origen antes de realizar una conmutación al origen secundario (en el caso de un grupo de orígenes) o devolver una respuesta de error al lector. De forma predeterminada, CloudFront espera hasta 30 segundos (3 intentos de 10 segundos cada uno) antes de intentar conectarse al origen secundario o devolver una respuesta de error. Puede reducir este tiempo si especifica menos intentos, un tiempo de espera de conexión más corto o ambas opciones.
Para obtener más información, consulte [Control de tiempos de espera e intentos de origen](high_availability_origin_failover.md#controlling-attempts-and-timeouts).
### Tiempo de espera de respuesta de origen
El *tiempo de espera de respuesta del origen*, también conocido como *tiempo de espera de lectura del origen* y *tiempo de espera de solicitud al origen*, se aplica a los dos siguientes:
+ El periodo de tiempo, en segundos, que CloudFront espera una respuesta después de enviar una solicitud al origen.
+ El periodo de tiempo, en segundos, que CloudFront espera después de recibir un paquete de una respuesta del origen y antes de recibir el paquete siguiente.
El comportamiento de CloudFront depende del método HTTP en la solicitud del lector:
+ Solicitudes `GET` y `HEAD`: si el origen no responde en un plazo de 30 segundos o deja de responder durante 30 segundos, CloudFront interrumpe la conexión. Si el número especificado de [intentos de conexión de origen](DownloadDistValuesOrigin.md#origin-connection-attempts) es superior a 1, CloudFront intenta obtener de nuevo una respuesta completa. CloudFront lo intenta hasta tres veces, según lo determinado por el valor de la opción*Origin connection attempts (Intentos de conexión de origen)*. Si el origen no responde en el último intento, CloudFront no vuelve a intentarlo hasta que recibe una nueva solicitud de contenido en el mismo origen.
+ Solicitudes `DELETE`, `OPTIONS`, `PATCH`, `PUT` y `POST`: si el origen no responde en 30 segundos, CloudFront interrumpe la conexión y no vuelve a intentar ponerse en contacto con el origen. El cliente puede volver a enviar la solicitud en caso de que sea necesario.
No puede cambiar el tiempo de espera de respuesta para un origen de Amazon S3 (un bucket de S3 que *no* está configurado con alojamiento de sitio web estático).
### Solicitudes simultáneas del mismo objeto (contracción de solicitudes)
Cuando una ubicación periférica de CloudFront recibe una solicitud de un objeto y este no se encuentra en la caché o el objeto ha caducado, CloudFront envía inmediatamente la solicitud al origen. Sin embargo, si hay solicitudes simultáneas del mismo objeto, es decir, si llegan solicitudes adicionales del mismo objeto (con la misma clave de caché) a la ubicación periférica antes de que CloudFront reciba la respuesta a la primera solicitud, CloudFront se pone en pausa antes de reenviar las solicitudes adicionales al origen. Esta breve pausa ayuda a reducir la carga en el origen. CloudFront envía la respuesta de la solicitud original a todas las solicitudes que recibió mientras estaba en pausa. Esto se llama *contracción de solicitudes*. En los registros de CloudFront, la primera solicitud se identifica como `Miss` en el campo `x-edge-result-type`, y las solicitudes contraídas se identifican como `Hit`. Para obtener más información sobre los registros de CloudFront, consulte [Registro de funciones de CloudFront y perimetrales](logging.md).
CloudFront solo contrae las solicitudes que comparten [*clave de caché*](understanding-the-cache-key.md). Si las solicitudes adicionales no son idénticas, porque, por ejemplo, ha configurado CloudFront para almacenar en caché en función de los encabezados de solicitudes o las cadenas de consulta, CloudFront reenvía todas las solicitudes únicas a su origen.
Si quiere evitar la contracción de todas las solicitudes, puede utilizar la política de caché administrada `CachingDisabled`, que también impide el almacenamiento en caché. Para obtener más información, consulte [Uso de políticas de caché administradas](using-managed-cache-policies.md).
Si quiere evitar la contracción de la solicitud para objetos específicos, puede establecer el TTL mínimo para el comportamiento de la caché en 0 *y* configurar el origen para enviar `Cache-Control: private`, `Cache-Control: no-store`, `Cache-Control: no-cache`, `Cache-Control: max-age=0` o `Cache-Control: s-maxage=0`. Estas configuraciones aumentarán la carga en el origen e introducirán latencia adicional para las solicitudes simultáneas que se detienen mientras CloudFront espera la respuesta a la primera solicitud.
**importante**
Actualmente, CloudFront no admite la contracción de solicitudes si se habilita el reenvío de cookies en la [política de caché](controlling-the-cache-key.md), la [política de solicitudes de origen](controlling-origin-requests.md) o la configuración de caché antigua.
## Cómo procesa CloudFront las respuestas de su origen de Amazon S3
Obtenga información sobre cómo procesa CloudFront las respuestas de su origen de Amazon S3
**Contents**
+ [Solicitudes canceladas](#response-s3-canceled-requests)
+ [Encabezados de respuesta HTTP que CloudFront elimina o actualiza](#response-s3-removed-headers)
+ [Tamaño máximo de archivo que se puede almacenar en caché](#ResponseS3MaxFileSize)
+ [Redireccionamientos](#ResponseS3Redirects)
### Solicitudes canceladas
Si un objeto no está en la caché perimetral y un lector termina una sesión (por ejemplo, cierra un navegador) después de que CloudFront obtiene el objeto solicitado del origen, pero antes de que pueda entregarlo, CloudFront no almacena el objeto en la caché de la ubicación periférica.
### Encabezados de respuesta HTTP que CloudFront elimina o actualiza
CloudFront elimina o actualiza los siguientes campos de encabezado antes de reenviar la respuesta desde su origen de Amazon S3 al lector:
+ `X-Amz-Id-2`
+ `X-Amz-Request-Id`
+ `Set-Cookie`: si configura CloudFront para reenviar cookies, reenviará el campo del encabezado `Set-Cookie` a los clientes. Para obtener más información, consulte [Almacenamiento en caché de contenido en función de cookies](Cookies.md).
+ `Trailer`
+ `Transfer-Encoding`: si el origen de Amazon S3 devuelve este campo de encabezado CloudFront establece el valor en `chunked` antes de devolver la respuesta al lector.
+ `Upgrade`
+ `Via`: CloudFront establece el valor en lo siguiente en la respuesta al lector:
`Via: `*versión-http* *cadena-alfanumérica*`.cloudfront.net (CloudFront)`
Por ejemplo, el valor será similar a lo siguiente:
`Via: 1.1 1026589cc7887e7a0dc7827b4example.cloudfront.net (CloudFront)`
### Tamaño máximo de archivo que se puede almacenar en caché
El tamaño máximo de un cuerpo de respuesta que CloudFront guarda en su caché es de 50 GB. Eso incluye respuestas transferidas en fragmentos que no especifican el valor de encabezado `Content-Length`.
Puede utilizar CloudFront para almacenar en caché un objeto superior a este tamaño mediante solicitudes de rango para solicitar los objetos en partes de 50 GB o menos cada una. CloudFront almacena en caché estas partes porque cada una de ellas es de 50 GB o menos. Una vez que el lector recupera todas las partes del objeto, puede reconstruir el objeto original de mayor tamaño. Para obtener más información, consulte [Uso de solicitudes de rango para almacenar en caché objetos grandes](RangeGETs.md#cache-large-objects-with-range-requests).
### Redireccionamientos
Puede configurar un bucket de Amazon S3 para redirigir todas las solicitudes a otro nombre de host; este puede ser otro bucket de Amazon S3 o un servidor HTTP. Si configura un bucket para redirigir todas las solicitudes y es el origen de una distribución de CloudFront, le recomendamos configurarlo para redirigirlas a una distribución de CloudFront utilizando el nombre de dominio para la distribución (por ejemplo, d111111abcdef8.cloudfront.net) o un nombre alternativo de dominio (un CNAME) asociado a una distribución (por ejemplo, ejemplo.com). De lo contrario, las solicitudes de los lectores eluden CloudFront y los objetos se sirven directamente desde el nuevo origen.
**nota**
Si redirige solicitudes a un nombre de dominio alternativo, también debe actualizar el servicio de DNS del dominio mediante la adición de un registro CNAME. Para obtener más información, consulte [Uso de URL personalizadas añadiendo nombres de dominio alternativos (CNAME)](CNAMEs.md).
Esto es lo que ocurre cuando configura un bucket para redirigir todas las solicitudes:
1. Un lector (por ejemplo, un navegador) solicita un objeto de CloudFront.
1. CloudFront reenvía la solicitud al bucket de Amazon S3 que es el origen de la distribución.
1. Amazon S3 devuelve un código de estado HTTP 301 (movido permanentemente) y la nueva ubicación.
1. CloudFront almacena en caché el código de estado de la redirección y la nueva ubicación, y devuelve los valores al lector. CloudFront no sigue la redirección para obtener el objeto de la nueva ubicación.
1. El lector envía otra solicitud del objeto, pero esta vez el lector especifica la nueva ubicación que obtuvo de CloudFront:
+ Si el bucket de Amazon S3 está redirigiendo todas las solicitudes a una distribución de CloudFront usando el nombre de dominio para la distribución o un nombre de dominio alternativo, CloudFront solicita el objeto del bucket de Amazon S3 o del servidor HTTP en la nueva ubicación. Cuando la nueva ubicación devuelve el objeto, CloudFront lo devuelve al lector y lo almacena en caché en una ubicación periférica.
+ Si el bucket de Amazon S3 está redirigiendo las solicitudes a otra ubicación, la segunda solicitud elude CloudFront. El bucket de Amazon S3 o el servidor HTTP de la nueva ubicación devuelven el objeto directamente al lector, por lo que el objeto nunca se almacena en una caché perimetral de CloudFront.
# Comportamiento de solicitudes y respuestas para orígenes personalizados
Para entender cómo CloudFront procesa solicitudes y respuestas cuando se está utilizando orígenes personalizados, consulte las secciones siguientes:
**Topics**
+ [Cómo procesa y reenvía CloudFront solicitudes a su origen personalizado](#RequestBehaviorCustomOrigin)
+ [Cómo procesa CloudFront las respuestas de su origen personalizado](#ResponseBehaviorCustomOrigin)
## Cómo procesa y reenvía CloudFront solicitudes a su origen personalizado
Obtenga información sobre cómo CloudFront procesa solicitudes de lectores y las reenvía a su origen personalizado.
**Contents**
+ [Autenticación](#RequestCustomClientAuth)
+ [Duración de almacenamiento en caché y TTL mínimo](#RequestCustomCaching)
+ [Direcciones IP de clientes](#RequestCustomIPAddresses)
+ [Autenticación SSL en el cliente](#RequestCustomClientSideSslAuth)
+ [Compresión](#RequestCustomCompression)
+ [Solicitudes condicionales](#RequestCustomConditionalGETs)
+ [Cookies](#RequestCustomCookies)
+ [Compartir recursos entre orígenes (CORS)](#request-custom-cors)
+ [Cifrado](#RequestCustomEncryption)
+ [Solicitudes GET que incluyen un cuerpo](#RequestCustom-get-body)
+ [Métodos HTTP](#RequestCustomHTTPMethods)
+ [Encabezados de solicitudes HTTP y comportamiento de CloudFront (personalizado y orígenes de Amazon S3)](#request-custom-headers-behavior)
+ [Versión de HTTP](#RequestCustomHTTPVersion)
+ [Longitud máxima de una solicitud y de una URL](#RequestCustomMaxRequestStringLength)
+ [Asociación de OCSP](#request-custom-ocsp-stapling)
+ [Conexiones persistentes](#request-custom-persistent-connections)
+ [Protocolos](#RequestCustomProtocols)
+ [Cadenas de consulta](#RequestCustomQueryStrings)
+ [Tiempo de espera e intentos de conexión de origen](#custom-origin-timeout-attempts)
+ [Tiempo de espera de respuesta de origen](#request-custom-request-timeout)
+ [Solicitudes simultáneas del mismo objeto (contracción de solicitudes)](#request-custom-traffic-spikes)
+ [`User-Agent`Encabezado](#request-custom-user-agent-header)
### Autenticación
Si reenvía el encabezado `Authorization` a su origen, puede configurar el servidor de origen a fin de solicitar autenticación del cliente para los siguientes tipos de solicitudes:
+ `DELETE`
+ `GET`
+ `HEAD`
+ `PATCH`
+ `PUT`
+ `POST`
Para las solicitudes `OPTIONS`, la autenticación del cliente *solo* se puede configurar si utiliza las siguientes opciones de CloudFront:
+ CloudFront se ha configurado para reenviar el encabezado `Authorization` al origen.
+ CloudFront se ha configurado para que *no* almacene en caché la respuesta a solicitudes `OPTIONS`.
Para obtener más información, consulte [Configuración de CloudFront para reenviar el encabezado de `Authorization`](add-origin-custom-headers.md#add-origin-custom-headers-forward-authorization).
Puede utilizar HTTP o HTTPS para reenviar las solicitudes al servidor de origen. Para obtener más información, consulte [Uso de HTTPS con CloudFront](using-https.md).
### Duración de almacenamiento en caché y TTL mínimo
Para controlar durante cuánto tiempo se mantienen los objetos en una caché de CloudFront antes de que CloudFront reenvíe otra solicitud al origen, puede:
+ Configure su origen para añadir un `Cache-Control` o un encabezado `Expires` para cada objeto.
+ Especificar un valor de TTL mínimo en comportamientos de la caché de CloudFront.
+ Utilice el valor de predeterminado de 24 horas.
Para obtener más información, consulte [Administración de cuánto tiempo se mantiene el contenido en una caché (vencimiento)](Expiration.md).
### Direcciones IP de clientes
Si un lector envía una solicitud a CloudFront y no incluye un encabezado de solicitud `X-Forwarded-For`, CloudFront obtiene la dirección IP del lector de la conexión TCP, agrega un encabezado `X-Forwarded-For` que incluya la dirección IP y reenvía la solicitud al origen. Por ejemplo, si CloudFront obtiene la dirección IP `192.0.2.2` de la conexión TCP, reenvía el siguiente encabezado al origen:
`X-Forwarded-For: 192.0.2.2`
Si un lector envía una solicitud a CloudFront e incluye un encabezado de solicitud `X-Forwarded-For`, CloudFront obtiene la dirección IP del lector de la conexión TCP, la agrega al final del encabezado `X-Forwarded-For` que incluya la dirección IP y reenvía la solicitud al origen. Por ejemplo, si la solicitud del lector incluye `X-Forwarded-For: 192.0.2.4,192.0.2.3` y CloudFront obtiene la dirección IP `192.0.2.2` de la conexión TCP, reenvía el siguiente encabezado al origen:
`X-Forwarded-For: 192.0.2.4,192.0.2.3,192.0.2.2`
Algunas aplicaciones, como, por ejemplo, equilibradores de carga (incluido Elastic Load Balancing), firewalls de aplicaciones web, proxis inversos, sistemas de prevención de intrusos y API Gateway, agregan la dirección IP del servidor de borde de CloudFront que reenvía la solicitud al extremo del encabezado `X-Forwarded-For`. Por ejemplo, si CloudFront incluye `X-Forwarded-For: 192.0.2.2` en una solicitud que reenvía a ELB y si la dirección IP del servidor periférico de CloudFront es 192.0.2.199, la solicitud que recibe su instancia EC2 contiene el siguiente encabezado:
`X-Forwarded-For: 192.0.2.2,192.0.2.199`
**nota**
El encabezado `X-Forwarded-For` contiene direcciones IPv4 (como 192.0.2.44) e IPv6 (como 2001:0db8:85a3::8a2e:0370:7334).
Tenga en cuenta también que todos los nodos de la ruta al servidor actual (CloudFront) pueden modificar el encabezado `X-Forwarded-For`. Para obtener más información, consulte la sección 8.1 de [RFC 7239](https://datatracker.ietf.org/doc/html/rfc7239). También puede modificar el encabezado mediante las funciones de computación en la periferia de CloudFront.
### Autenticación SSL en el cliente
CloudFront admite la autenticación TLS mutua (mTLS), en la que tanto el cliente como el servidor se autentican entre sí mediante certificados. Con mTLS configurado, CloudFront puede validar los certificados de los clientes durante el establecimiento de comunicación de TLS y, de forma opcional, ejecutar CloudFront Functions para implementar una lógica de validación personalizada.
Para orígenes que solicitan certificados del cliente cuando mTLS no está configurado, CloudFront interrumpe la solicitud.
Para obtener más información sobre la configuración de mTLS, consulte [Asociación de una función de conexión de CloudFront](connection-functions.md).
CloudFront no admite la autenticación del cliente con certificados SSL del lado del cliente. Si un origen solicita un certificado de cliente, CloudFront interrumpe la solicitud.
### Compresión
Para obtener más información, consulte [Ofrecimiento de archivos comprimidos](ServingCompressedFiles.md).
### Solicitudes condicionales
Cuando CloudFront recibe una solicitud de un objeto que ha caducado en una caché perimetral, reenvía la solicitud al origen para obtener la última versión del objeto o para obtener la confirmación del origen de que la caché perimetral de CloudFront ya dispone de la última versión. Por lo general, la última vez que el origen envía el objeto a CloudFront, incluye un valor `ETag`, un valor `LastModified` o ambos en la respuesta. En la nueva solicitud que CloudFront reenvía al origen, CloudFront agrega uno o ambos de los siguientes elementos:
+ Un encabezado `If-Match` o `If-None-Match` que contenga el valor `ETag` para la versión caducada del objeto.
+ Un encabezado `If-Modified-Since` que contenga el valor `LastModified` para la versión caducada del objeto.
El origen utiliza esta información para determinar si el objeto se ha actualizado y, en consecuencia, devolver todo el objeto a CloudFront o devolver solo un código de estado HTTP 304 (no modificado).
**nota**
Las solicitudes condicionales `If-Modified-Since` y `If-None-Match` no son compatibles cuando CloudFront se configura para reenviar cookies (todas o un subconjunto).
Para obtener más información, consulte [Almacenamiento en caché de contenido en función de cookies](Cookies.md).
### Cookies
Puede configurar CloudFront para que reenvíe cookies al origen. Para obtener más información, consulte [Almacenamiento en caché de contenido en función de cookies](Cookies.md).
### Compartir recursos entre orígenes (CORS)
Si desea que CloudFront respete la configuración de intercambio de recursos entre orígenes, configure `Origin` para que reenvíe el encabezado al origen. Para obtener más información, consulte [Almacenamiento en caché de contenido en función de encabezados de solicitud](header-caching.md).
### Cifrado
Puede requerir que los lectores utilicen HTTPS para enviar solicitudes a CloudFront y exigir a CloudFront que reenvíe las solicitudes a su origen personalizado mediante el protocolo que utiliza el lector. Para obtener más información, consulte la siguiente configuración de distribución:
+ [Política de protocolo para lectores](DownloadDistValuesCacheBehavior.md#DownloadDistValuesViewerProtocolPolicy)
+ [Protocolo (solo orígenes personalizados)](DownloadDistValuesOrigin.md#DownloadDistValuesOriginProtocolPolicy)
CloudFront reenvía las solicitudes HTTPS al servidor de origen mediante los protocolos SSLv3, TLSv1.0, TLSv1.1, TLSv1.2 y TLSv1.3. En el caso de orígenes personalizados, puede elegir los protocolos SSL que desea que CloudFront utilice al comunicarse con su origen:
+ Si utiliza la consola de CloudFront, elija los protocolos en las casillas **Origin SSL Protocols (Protocolos SSL de origen)**. Para obtener más información, consulte [Creación de una distribución](distribution-web-creating-console.md).
+ Si utiliza la API de CloudFront, especifique los protocolos mediante el elemento `OriginSslProtocols`. Para obtener más información, consulte [OriginSslProtocols](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_OriginSslProtocols.html) y [DistributionConfig](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_DistributionConfig.html) en la *Referencia de la API de Amazon CloudFront*.
Si el origen es un bucket de Amazon S3, CloudFront utilizará de forma predeterminada TLSv1.3.
**importante**
Otras versiones de SSL y TLS no son compatibles.
Para obtener más información acerca del uso de HTTPS con CloudFront, consulte [Uso de HTTPS con CloudFront](using-https.md). Para obtener listas de los algoritmos criptográficos que CloudFront admite para la comunicación HTTPS entre lectores y CloudFront, y entre CloudFront y su origen, consulte [Protocolos y cifrados admitidos entre lectores y CloudFront](secure-connections-supported-viewer-protocols-ciphers.md).
### Solicitudes GET que incluyen un cuerpo
Si una solicitud `GET` del lector incluye un cuerpo, CloudFront devuelve un código de estado HTTP 403 (prohibido) al lector.
### Métodos HTTP
Si configura CloudFront para procesar todos los métodos de HTTP que admite, CloudFront acepta las siguientes solicitudes de los lectores y las reenvía al origen personalizado:
+ `DELETE`
+ `GET`
+ `HEAD`
+ `OPTIONS`
+ `PATCH`
+ `POST`
+ `PUT`
CloudFront siempre almacena en caché las respuestas a las solicitudes `GET` y `HEAD`. También puede configurar CloudFront para almacenar en caché las respuestas a solicitudes `OPTIONS`. CloudFront no almacena en caché las respuestas a las solicitudes que utilizan los otros métodos.
Para obtener más información acerca de la configuración para que su origen personalizado procese estos métodos, consulte la documentación de su origen.
**importante**
Si configura CloudFront para aceptar y reenviar al origen todos los métodos HTTP que admite CloudFront, configure su servidor de origen para administrar todos los métodos. Por ejemplo, si configura CloudFront para aceptar y reenviar estos métodos porque desea utilizar `POST`, debe configurar también su servidor de origen para administrar las solicitudes `DELETE` adecuadamente, de forma que los lectores no puedan eliminar los recursos que no desee que eliminen. Para obtener más información, consulte la documentación de su servidor HTTP.
### Encabezados de solicitudes HTTP y comportamiento de CloudFront (personalizado y orígenes de Amazon S3)
En la siguiente tabla se indican los encabezados de solicitudes HTTP que puede reenviar a orígenes personalizados y de Amazon S3 (con las excepciones que se indican). Para cada encabezado, la tabla incluye información acerca de lo siguiente:
+ El comportamiento de CloudFront si no configura CloudFront para reenviar el encabezado a su origen, lo que hace que CloudFront almacene en caché los objetos en función de los valores de encabezado.
+ Si puede configurar CloudFront para almacenar en caché los objetos en función de los valores de ese encabezado.
Puede configurar CloudFront para almacenar en caché los objetos en función de los valores de los encabezados `Date` y `User-Agent`, pero no lo recomendamos. Estos encabezados tienen muchos valores posibles y el almacenamiento en caché en función de sus valores podría hacer que CloudFront reenvíe una cantidad de solicitudes significativamente mayor a su origen.
Para obtener más información acerca del almacenamiento en caché en función de valores de encabezado, consulte [Almacenamiento en caché de contenido en función de encabezados de solicitud](header-caching.md).
| Encabezado | Comportamiento si no configura CloudFront para almacenar en caché en función de los valores de encabezados | Se admite el almacenamiento en caché admite en función de valores de encabezados |
| --- | --- | --- |
| Encabezados definidos por otros | **Configuración de caché heredada**: CloudFront reenvía los encabezados al origen. | Sí |
| `Accept` | CloudFront elimina el encabezado. | Sí |
| `Accept-Charset` | CloudFront elimina el encabezado. | Sí |
| `Accept-Encoding` | Si el valor contiene `gzip` o `br`, CloudFront reenvía un encabezado `Accept-Encoding` normalizado a su origen. Para obtener más información, consulte [Compatibilidad con la compresión](cache-key-understand-cache-policy.md#cache-policy-compressed-objects) y [Ofrecimiento de archivos comprimidos](ServingCompressedFiles.md). | Sí |
| `Accept-Language` | CloudFront elimina el encabezado. | Sí |
| `Authorization` | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html) | Sí |
| `Cache-Control` | CloudFront reenvía los encabezados al origen. | No |
| `CloudFront-Forwarded-Proto` | CloudFront no agrega el encabezado antes de reenviar la solicitud al origen. Para obtener más información, consulte [Configuración del almacenamiento en caché en función del protocolo de la solicitud](header-caching.md#header-caching-web-protocol). | Sí |
| `CloudFront-Is-Desktop-Viewer` | CloudFront no agrega el encabezado antes de reenviar la solicitud al origen. Para obtener más información, consulte [Configuración del almacenamiento en caché en función del tipo de dispositivo](header-caching.md#header-caching-web-device). | Sí |
| `CloudFront-Is-Mobile-Viewer` | CloudFront no agrega el encabezado antes de reenviar la solicitud al origen. Para obtener más información, consulte [Configuración del almacenamiento en caché en función del tipo de dispositivo](header-caching.md#header-caching-web-device). | Sí |
| `CloudFront-Is-Tablet-Viewer` | CloudFront no agrega el encabezado antes de reenviar la solicitud al origen. Para obtener más información, consulte [Configuración del almacenamiento en caché en función del tipo de dispositivo](header-caching.md#header-caching-web-device). | Sí |
| `CloudFront-Viewer-Country` | CloudFront no agrega el encabezado antes de reenviar la solicitud al origen. | Sí |
| `Connection` | CloudFront sustituye este encabezado por `Connection: Keep-Alive` antes de enviar la solicitud a su origen. | No |
| `Content-Length` | CloudFront reenvía los encabezados al origen. | No |
| `Content-MD5` | CloudFront reenvía los encabezados al origen. | Sí |
| `Content-Type` | CloudFront reenvía los encabezados al origen. | Sí |
| `Cookie` | Si configura CloudFront para reenviar cookies, reenviará el campo del encabezado `Cookie` a su origen. En caso contrario, CloudFront elimina el campo de encabezado `Cookie`. Para obtener más información, consulte [Almacenamiento en caché de contenido en función de cookies](Cookies.md). | No |
| `Date` | CloudFront reenvía los encabezados al origen. | Sí, pero no se recomienda |
| `Expect` | CloudFront elimina el encabezado. | Sí |
| `From` | CloudFront reenvía los encabezados al origen. | Sí |
| `Host` | CloudFront establece el valor en el nombre de dominio del origen que se asocia al objeto solicitado. No puede almacenar en caché en función del encabezado Host para los orígenes de Amazon S3 o MediaStore. | Sí (personalizado) No (S3 y MediaStore) |
| `If-Match` | CloudFront reenvía los encabezados al origen. | Sí |
| `If-Modified-Since` | CloudFront reenvía los encabezados al origen. | Sí |
| `If-None-Match` | CloudFront reenvía los encabezados al origen. | Sí |
| `If-Range` | CloudFront reenvía los encabezados al origen. | Sí |
| `If-Unmodified-Since` | CloudFront reenvía los encabezados al origen. | Sí |
| `Max-Forwards` | CloudFront reenvía los encabezados al origen. | No |
| `Origin` | CloudFront reenvía los encabezados al origen. | Sí |
| `Pragma` | CloudFront reenvía los encabezados al origen. | No |
| `Proxy-Authenticate` | CloudFront elimina el encabezado. | No |
| `Proxy-Authorization` | CloudFront elimina el encabezado. | No |
| `Proxy-Connection` | CloudFront elimina el encabezado. | No |
| `Range` | CloudFront reenvía los encabezados al origen. Para obtener más información, consulte [Cómo CloudFront procesa las solicitudes parciales de un objeto (rango GET)](RangeGETs.md). | Sí de forma predeterminada |
| `Referer` | CloudFront elimina el encabezado. | Sí |
| `Request-Range` | CloudFront reenvía los encabezados al origen. | No |
| `TE` | CloudFront elimina el encabezado. | No |
| `Trailer` | CloudFront elimina el encabezado. | No |
| `Transfer-Encoding` | CloudFront reenvía los encabezados al origen. | No |
| `Upgrade` | CloudFront elimina el encabezado, a menos que haya establecido una conexión WebSocket. | No (excepto para las conexiones WebSocket) |
| `User-Agent` | CloudFront sustituye el valor de este campo de encabezado por `Amazon CloudFront`. Si desea que CloudFront almacene en caché el contenido en función del dispositivo del usuario, consulte [Configuración del almacenamiento en caché en función del tipo de dispositivo](header-caching.md#header-caching-web-device). | Sí, pero no se recomienda |
| `Via` | CloudFront reenvía los encabezados al origen. | Sí |
| `Warning` | CloudFront reenvía los encabezados al origen. | Sí |
| `X-Amz-Cf-Id` | CloudFront agrega el encabezado a la solicitud del lector antes de reenviar la solicitud al origen. El valor de encabezado contiene una cadena cifrada que identifica la solicitud de forma única. | No |
| `X-Edge-*` | CloudFront elimina todos los encabezados `X-Edge-*`. | No |
| `X-Forwarded-For` | CloudFront reenvía los encabezados al origen. Para obtener más información, consulte [Direcciones IP de clientes](#RequestCustomIPAddresses). | Sí |
| `X-Forwarded-Proto` | CloudFront elimina el encabezado. | No |
| `X-HTTP-Method-Override` | CloudFront elimina el encabezado. | Sí |
| `X-Real-IP` | CloudFront elimina el encabezado. | No |
### Versión de HTTP
CloudFront reenvía las solicitudes a su origen personalizado mediante HTTP/1.1.
### Longitud máxima de una solicitud y de una URL
La longitud máxima de una solicitud, incluida la ruta, la cadena de consulta (si procede) y los encabezados, es 20 480 bytes.
CloudFront crea una URL a partir de la solicitud. La longitud máxima de esta URL es de 8 192 bytes.
Si una solicitud o una URL supera estos máximos, CloudFront devuelve el código de estado HTTP 413 (entidad de solicitud demasiado grande), al lector y, a continuación, interrumpe la conexión TCP con el lector.
### Asociación de OCSP
Cuando un lector envía una solicitud de un objeto HTTPS, CloudFront o el lector deben confirmar con la autoridad de certificación (CA) que el certificado SSL del dominio no se ha revocado. La asociación de OCSP agiliza la validación de certificados al permitir a CloudFront validar el certificado y almacenar en caché la respuesta de la CA, por lo que el cliente no tiene por qué validar el certificado directamente con la CA.
La mejora en el rendimiento de la asociación de OCSP es más notoria cuando CloudFront recibe numerosas solicitudes HTTPS de objetos en el mismo dominio. Cada servidor en una ubicación periférica de CloudFront debe enviar una solicitud de validación independiente. Cuando CloudFront recibe una gran cantidad de solicitudes HTTPS para el mismo dominio, cada servidor de la ubicación periférica obtiene pronto una respuesta de la CA que puede asociar a un paquete en el protocolo de enlace de SSL; cuando el lector considera que el certificado es válido, CloudFront puede ofrecer el objeto solicitado. Si la distribución no recibe mucho tráfico en una ubicación periférica de CloudFront, es más probable que las nuevas solicitudes se dirijan a un servidor que todavía no haya validado el certificado con la CA. En ese caso, el lector realiza el paso de validación por separado y el servidor de CloudFront ofrece el objeto. Este servidor de CloudFront también envía una solicitud de validación a la CA, por lo que la próxima vez que recibe una solicitud que incluye el mismo nombre de dominio, cuenta con una respuesta de validación de la CA.
### Conexiones persistentes
Cuando CloudFront obtiene una respuesta de su origen, intenta mantener la conexión durante varios segundos en caso de que otra solicitud llegue durante ese periodo. Garantizar una conexión persistente ahorra el tiempo necesario para restablecer la conexión TCP y realizar otro protocolo de enlace TLS para solicitudes posteriores.
Para obtener más información, incluido el modo de configurar la duración de las conexiones persistentes, consulte [Tiempo de espera de keep-alive (solo orígenes personalizados y de VPC)](DownloadDistValuesOrigin.md#DownloadDistValuesOriginKeepaliveTimeout) en la sección [Referencia de toda la configuración de distribución](distribution-web-values-specify.md).
### Protocolos
CloudFront reenvía solicitudes HTTP o HTTPS al servidor de origen en función de lo siguiente:
+ El protocolo de la solicitud que el lector envía a CloudFront, ya sea HTTP o HTTPS.
+ El valor del campo **Origin Protocol Policy (Política de protocolo de origen)** en la consola de CloudFront o, si está utilizando la API de CloudFront, el elemento `OriginProtocolPolicy` del tipo complejo `DistributionConfig`. En la consola de CloudFront, las opciones son **HTTP Only (Solo HTTP)**, **HTTPS Only (Solo HTTPS)** y **Match Viewer (Coincidir con lector)**.
Si especifica **HTTP Only (Solo HTTP)** o **HTTPS Only (Solo HTTPS)**, CloudFront reenvía las solicitudes al servidor de origen mediante el protocolo especificado, independientemente del protocolo de la solicitud del lector.
Si especifica **Match Viewer (Coincidir con lector)**, CloudFront reenvía las solicitudes al servidor de origen mediante el protocolo especificado en la solicitud del lector. Tenga en cuenta que CloudFront almacena en caché el objeto solo una vez, incluso si los lectores realizan solicitudes a través de los protocolos HTTP y HTTPS.
**importante**
Si CloudFront reenvía una solicitud al origen mediante el protocolo HTTPS, y si el servidor de origen devuelve un certificado no válido o autofirmado, CloudFront interrumpe la conexión TCP.
Para obtener más información acerca de cómo actualizar una distribución desde la consola de CloudFront, consulte [Actualizar una distribución](HowToUpdateDistribution.md). Para obtener información acerca de cómo actualizar una distribución mediante la API de CloudFront, consulte [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html) en la *Referencia de la API de Amazon CloudFront*.
### Cadenas de consulta
Puede configurar si CloudFront reenvía parámetros de cadenas de consulta a su origen. Para obtener más información, consulte [Almacenamiento en caché de contenido en función de parámetros de cadenas de consulta](QueryStringParameters.md).
### Tiempo de espera e intentos de conexión de origen
*Origin connection timeout (Tiempo de espera de conexión de origen)* es el número de segundos que CloudFront espera al intentar establecer una conexión con el origen.
*Origin connection attempts (Intentos de conexión de origen)* es el número de veces que CloudFront intenta conectarse al origen.
Juntos, estos parámetros determinan cuánto tiempo intenta CloudFront conectarse al origen antes de realizar una conmutación al origen secundario (en el caso de un grupo de orígenes) o devolver una respuesta de error al lector. De forma predeterminada, CloudFront espera hasta 30 segundos (3 intentos de 10 segundos cada uno) antes de intentar conectarse al origen secundario o devolver una respuesta de error. Puede reducir este tiempo si especifica menos intentos, un tiempo de espera de conexión más corto o ambas opciones.
Para obtener más información, consulte [Control de tiempos de espera e intentos de origen](high_availability_origin_failover.md#controlling-attempts-and-timeouts).
### Tiempo de espera de respuesta de origen
El *tiempo de espera de respuesta del origen*, también conocido como *tiempo de espera de lectura del origen* y *tiempo de espera de solicitud al origen*, se aplica a los dos siguientes:
+ El periodo de tiempo, en segundos, que CloudFront espera una respuesta después de enviar una solicitud al origen.
+ El periodo de tiempo, en segundos, que CloudFront espera después de recibir un paquete de una respuesta del origen y antes de recibir el paquete siguiente.
El comportamiento de CloudFront depende del método HTTP en la solicitud del lector:
+ Solicitudes `GET` y `HEAD`: si el origen no responde o deja de responder durante el tiempo de espera de la respuesta, CloudFront interrumpe la conexión. Si el número especificado de [intentos de conexión de origen](DownloadDistValuesOrigin.md#origin-connection-attempts) es superior a 1, CloudFront intenta obtener de nuevo una respuesta completa. CloudFront lo intenta hasta tres veces, según lo determinado por el valor de la opción*Origin connection attempts (Intentos de conexión de origen)*. Si el origen no responde en el último intento, CloudFront no vuelve a intentarlo hasta que recibe una nueva solicitud de contenido en el mismo origen.
+ Solicitudes `DELETE`, `OPTIONS`, `PATCH`, `PUT` y `POST`: si el origen no responde mientras dura el tiempo de espera de lectura, CloudFront interrumpe la conexión y no vuelve a intentar ponerse en contacto con el origen. El cliente puede volver a enviar la solicitud en caso de que sea necesario.
Para obtener más información, incluido el modo de configurar el tiempo de espera de la respuesta del origen, consulte [Tiempo de espera de respuesta](DownloadDistValuesOrigin.md#DownloadDistValuesOriginResponseTimeout).
### Solicitudes simultáneas del mismo objeto (contracción de solicitudes)
Cuando una ubicación periférica de CloudFront recibe una solicitud de un objeto y este no se encuentra en la caché o el objeto ha caducado, CloudFront envía inmediatamente la solicitud al origen. Sin embargo, si hay solicitudes simultáneas del mismo objeto, es decir, si llegan solicitudes adicionales del mismo objeto (con la misma clave de caché) a la ubicación periférica antes de que CloudFront reciba la respuesta a la primera solicitud, CloudFront se pone en pausa antes de reenviar las solicitudes adicionales al origen. Esta breve pausa ayuda a reducir la carga en el origen. CloudFront envía la respuesta de la solicitud original a todas las solicitudes que recibió mientras estaba en pausa. Esto se llama *contracción de solicitudes*. En los registros de CloudFront, la primera solicitud se identifica como `Miss` en el campo `x-edge-result-type`, y las solicitudes contraídas se identifican como `Hit`. Para obtener más información sobre los registros de CloudFront, consulte [Registro de funciones de CloudFront y perimetrales](logging.md).
CloudFront solo contrae las solicitudes que comparten [*clave de caché*](understanding-the-cache-key.md). Si las solicitudes adicionales no son idénticas, porque, por ejemplo, ha configurado CloudFront para almacenar en caché en función de los encabezados de solicitudes o las cadenas de consulta, CloudFront reenvía todas las solicitudes únicas a su origen.
Si quiere evitar la contracción de todas las solicitudes, puede utilizar la política de caché administrada `CachingDisabled`, que también impide el almacenamiento en caché. Para obtener más información, consulte [Uso de políticas de caché administradas](using-managed-cache-policies.md).
Si quiere evitar la contracción de la solicitud para objetos específicos, puede establecer el TTL mínimo para el comportamiento de la caché en 0 *y* configurar el origen para enviar `Cache-Control: private`, `Cache-Control: no-store`, `Cache-Control: no-cache`, `Cache-Control: max-age=0` o `Cache-Control: s-maxage=0`. Estas configuraciones aumentarán la carga en el origen e introducirán latencia adicional para las solicitudes simultáneas que se detienen mientras CloudFront espera la respuesta a la primera solicitud.
**importante**
Actualmente, CloudFront no admite la contracción de solicitudes si se habilita el reenvío de cookies en la [política de caché](controlling-the-cache-key.md), la [política de solicitudes de origen](controlling-origin-requests.md) o la configuración de caché antigua.
### `User-Agent`Encabezado
Si desea que CloudFront almacene en caché diversas versiones de sus objetos según el dispositivo que el usuario utilice para ver su contenido, le recomendamos que configure CloudFront para que reenvíe uno o varios de los siguientes encabezados a su origen personalizado:
+ `CloudFront-Is-Desktop-Viewer`
+ `CloudFront-Is-Mobile-Viewer`
+ `CloudFront-Is-SmartTV-Viewer`
+ `CloudFront-Is-Tablet-Viewer`
En función del valor del encabezado `User-Agent`, CloudFront establece el valor de estos encabezados en `true` o `false` antes de reenviar la solicitud al origen. Si un dispositivo entra en más de una categoría, más de un valor podría ser `true`. Por ejemplo, en el caso de algunas tabletas, CloudFront podría establecer tanto `CloudFront-Is-Mobile-Viewer` como `CloudFront-Is-Tablet-Viewer` en `true`. Para obtener más información acerca de la configuración de CloudFront para almacenar en caché en función de los encabezados de solicitud, consulte [Almacenamiento en caché de contenido en función de encabezados de solicitud](header-caching.md).
Puede configurar CloudFront para almacenar en caché los objetos en función de los valores del encabezado `User-Agent`, pero no lo recomendamos. El encabezado `User-Agent` tiene muchos valores posibles y el almacenamiento en caché en función de esos valores podría hacer que CloudFront reenvíe una cantidad de solicitudes significativamente mayor a su origen.
Si no configura CloudFront para almacenar en caché los objetos en función de los valores del encabezado `User-Agent`, CloudFront agrega un encabezado `User-Agent` con el siguiente valor antes de reenviar una solicitud al origen:
`User-Agent = Amazon CloudFront`
CloudFront agrega este encabezado independientemente de si la solicitud del lector incluye un encabezado `User-Agent`. Si la solicitud del lector incluye un encabezado `User-Agent`, CloudFront lo elimina.
## Cómo procesa CloudFront las respuestas de su origen personalizado
Obtenga información sobre cómo procesa CloudFront las respuestas de su origen personalizado.
**Contents**
+ [`100 Continue` respuestas](#Response100Continue)
+ [Almacenamiento en caché](#ResponseCustomCaching)
+ [Solicitudes canceladas](#response-custom-canceled-requests)
+ [Negociación de contenido](#ResponseCustomContentNegotiation)
+ [Cookies](#ResponseCustomCookies)
+ [Conexiones TCP interrumpidas](#ResponseCustomDroppedTCPConnections)
+ [Encabezados de respuesta HTTP que CloudFront elimina o reemplaza](#ResponseCustomRemovedHeaders)
+ [Tamaño máximo de archivo que se puede almacenar en caché](#ResponseCustomMaxFileSize)
+ [Origen no disponible](#ResponseCustomOriginUnavailable)
+ [Redireccionamientos](#ResponseCustomRedirects)
+ [`Transfer-Encoding`Encabezado](#ResponseCustomTransferEncoding)
### `100 Continue` respuestas
Su origen no puede enviar más de una respuesta 100-Continue a CloudFront. Después de la primera respuesta 100-Continue, CloudFront espera una respuesta HTTP 200 OK. Si el origen envía otra respuesta 100-Continue después de la primera, CloudFront devolverá un error.
### Almacenamiento en caché
+ Asegúrese de que el servidor de origen establece valores válidos y precisos para los campos de encabezado `Date` y `Last-Modified`.
+ CloudFront normalmente respeta un encabezado `Cache-Control: no-cache` en la respuesta del origen. Para ver una excepción, consulte [Solicitudes simultáneas del mismo objeto (contracción de solicitudes)](#request-custom-traffic-spikes).
### Solicitudes canceladas
Si un objeto no está en la caché perimetral y un lector termina una sesión (por ejemplo, cierra un navegador) después de que CloudFront obtiene el objeto solicitado del origen, pero antes de que pueda entregarlo, CloudFront no almacena el objeto en la caché de la ubicación periférica.
### Negociación de contenido
Si el origen devuelve `Vary:*` en la respuesta y si el valor de **Minimum TTL (TTL mínimo)** para el comportamiento de la caché correspondiente es **0**, CloudFront almacena en caché el objeto, pero igualmente reenvía cada solicitud posterior del objeto al origen para confirmar que la caché contiene la última versión de dicho objeto. CloudFront no incluye encabezados condicionales, como `If-None-Match` o `If-Modified-Since`. Por tanto, el origen devuelve el objeto a CloudFront como respuesta a cada solicitud.
Si el origen devuelve `Vary:*` en la respuesta y si el valor de **TTL mínimo** para el comportamiento de la caché correspondiente es cualquier otro valor, CloudFront procesa el encabezado `Vary` tal y como se describe en [Encabezados de respuesta HTTP que CloudFront elimina o reemplaza](#ResponseCustomRemovedHeaders).
### Cookies
Si habilita cookies para un comportamiento de la caché y si el origen devuelve las cookies con un objeto, CloudFront almacena en la caché tanto el objeto como las cookies. Tenga en cuenta que este reduce la capacidad de almacenamiento en caché para un objeto. Para obtener más información, consulte [Almacenamiento en caché de contenido en función de cookies](Cookies.md).
### Conexiones TCP interrumpidas
Si la conexión TCP entre CloudFront y el origen se interrumpe al mismo tiempo que el origen devuelve un objeto a CloudFront, el comportamiento de CloudFront depende de si el origen incluye un encabezado `Content-Length` en la respuesta:
+ **Encabezado Content-Length**: CloudFront devuelve el objeto al lector mientras lo obtiene del origen. Sin embargo, si el valor del encabezado `Content-Length` no coincide con el tamaño del objeto, CloudFront no lo almacena en caché.
+ **Transfer-Encoding: Chunked**: CloudFront devuelve el objeto al lector mientras lo obtiene del origen. Sin embargo, si la respuesta fragmentada no está completa, CloudFront no almacena el objeto en la caché.
+ **Encabezado No Content-Length**: CloudFront devuelve el objeto al lector y lo almacena en la caché, pero el objeto puede no estar completo. Sin un encabezado `Content-Length`, CloudFront no puede determinar si la conexión TCP se interrumpió de forma accidental o intencionadamente.
Le recomendamos que configure su servidor HTTP para agregar un encabezado `Content-Length` y así evitar que CloudFront almacene en caché objetos parciales.
### Encabezados de respuesta HTTP que CloudFront elimina o reemplaza
CloudFront elimina o actualiza los siguientes campos de encabezado antes de reenviar la respuesta desde su origen al lector:
+ `Set-Cookie`: si configura CloudFront para reenviar cookies, reenviará el campo del encabezado `Set-Cookie` a los clientes. Para obtener más información, consulte [Almacenamiento en caché de contenido en función de cookies](Cookies.md).
+ `Trailer`
+ `Transfer-Encoding`: si el origen devuelve este campo de encabezado, CloudFront establece el valor en `chunked` antes de devolver la respuesta al lector.
+ `Upgrade`
+ `Vary`: tenga en cuenta lo siguiente:
+ Si configura CloudFront para reenviar cualquiera de los encabezados específicos del dispositivo al origen (`CloudFront-Is-Desktop-Viewer`, `CloudFront-Is-Mobile-Viewer`, `CloudFront-Is-SmartTV-Viewer`, `CloudFront-Is-Tablet-Viewer`) y configura su origen para devolver `Vary:User-Agent` a CloudFront, CloudFront devuelve `Vary:User-Agent` al lector. Para obtener más información, consulte [Configuración del almacenamiento en caché en función del tipo de dispositivo](header-caching.md#header-caching-web-device).
+ Si configura su origen para incluir bien `Accept-Encoding` o `Cookie` en el encabezado `Vary`, CloudFront incluye los valores en la respuesta al lector.
+ Si configura CloudFront para que reenvíe una lista blanca de encabezados al origen y, además, configura el origen para devolver los nombres de encabezado a CloudFront en el encabezado `Vary` (por ejemplo, `Vary:Accept-Charset,Accept-Language`), CloudFront devuelve el encabezado `Vary` con ese valor al lector.
+ Para obtener más información acerca de cómo CloudFront procesa un valor de `*` en el encabezado `Vary`, consulte [Negociación de contenido](#ResponseCustomContentNegotiation).
+ Si configura su origen para incluir cualquier otro valor en el encabezado `Vary`, CloudFront eliminará dichos valores antes de devolver la respuesta al lector.
+ `Via`: CloudFront establece el valor en lo siguiente en la respuesta al lector:
`Via: `*versión-http* *cadena-alfanumérica*`.cloudfront.net (CloudFront)`
Por ejemplo, el valor será similar a lo siguiente:
`Via: 1.1 1026589cc7887e7a0dc7827b4example.cloudfront.net (CloudFront)`
### Tamaño máximo de archivo que se puede almacenar en caché
El tamaño máximo de un cuerpo de respuesta que CloudFront guarda en su caché es de 50 GB. Eso incluye respuestas transferidas en fragmentos que no especifican el valor de encabezado `Content-Length`.
Puede utilizar CloudFront para almacenar en caché un objeto superior a este tamaño mediante solicitudes de rango para solicitar los objetos en partes de 50 GB o menos cada una. CloudFront almacena en caché estas partes porque cada una de ellas es de 50 GB o menos. Una vez que el lector recupera todas las partes del objeto, puede reconstruir el objeto original de mayor tamaño. Para obtener más información, consulte [Uso de solicitudes de rango para almacenar en caché objetos grandes](RangeGETs.md#cache-large-objects-with-range-requests).
### Origen no disponible
Si el servidor de origen no está disponible y CloudFront obtiene una solicitud de un objeto que se encuentra en la caché perimetral, pero que ha caducado (por ejemplo, porque el periodo especificado en la política `Cache-Control max-age` ya ha transcurrido), CloudFront ofrece esa versión caducada del objeto o una página de error personalizada. Para obtener más información sobre el comportamiento de CloudFront cuando se han configurado páginas de error personalizadas, consulte [Cómo CloudFront procesa los errores cuando las páginas de error personalizadas están configuradas](HTTPStatusCodes.md#HTTPStatusCodes-custom-error-pages).
En algunos casos, un objeto poco solicitado es desalojado y deja de estar disponible en la caché perimetral. CloudFront no puede servir un objeto que haya sido desalojado.
### Redireccionamientos
Si cambia la ubicación de un objeto en el servidor de origen, puede configurar su servidor web para redirigir las solicitudes a la nueva ubicación. Después de configurar el redireccionamiento, la primera vez que un lector envía una solicitud del objeto, CloudFront envía la solicitud al origen y el origen responde con un redireccionamiento (por ejemplo, `302 Moved Temporarily`). CloudFront almacena en caché el redireccionamiento y lo devuelve al lector. CloudFront no sigue el redireccionamiento.
Puede configurar su servidor web para redirigir las solicitudes a una de las siguientes ubicaciones:
+ La nueva URL del objeto en el servidor de origen. Cuando el lector sigue el redireccionamiento a la nueva URL, el lector elude CloudFront y va directamente al origen. Por tal motivo, le recomendamos que no redirija las solicitudes a la nueva URL del objeto en el origen.
+ La nueva URL de CloudFront para el objeto. Cuando el lector envía la solicitud que contiene la nueva URL de CloudFront, CloudFront obtiene el objeto de la nueva ubicación de su origen, lo almacena en la caché de la ubicación periférica y lo devuelve al lector. Las solicitudes posteriores del objeto serán atendidas por la ubicación periférica. Esto evita la latencia y carga asociadas a la solicitud del objeto al origen por parte de los espectadores. Sin embargo, cada nueva solicitud del objeto implicará cargos por concepto de dos solicitudes a CloudFront.
### `Transfer-Encoding`Encabezado
CloudFront admite únicamente el valor `chunked` del encabezado `Transfer-Encoding`. Si el origen devuelve `Transfer-Encoding: chunked`, CloudFront devuelve el objeto al cliente tan pronto como lo recibe la ubicación periférica y lo almacena en caché en formato fragmentado para solicitudes posteriores.
Si un lector envía una solicitud `Range GET` y el origen devuelve `Transfer-Encoding: chunked`, CloudFront devuelve el objeto entero al lector en lugar del intervalo solicitado.
Le recomendamos utilizar codificación fragmentada si la longitud de su respuesta no puede ser predeterminada. Para obtener más información, consulte [Conexiones TCP interrumpidas](#ResponseCustomDroppedTCPConnections).
# Comportamiento de solicitudes y respuestas para grupos de origen
Las solicitudes a un grupo de orígenes funcionan igual que las solicitudes a un origen que no está configurado como un grupo de orígenes, excepto cuando hay una conmutación por error de origen. Al igual que con cualquier otro origen, cuando CloudFront recibe una solicitud y el contenido ya está almacenado en caché en una ubicación periférica, el contenido se sirve a los lectores desde la caché. Cuando hay un error de caché, las solicitudes de lector se reenvían al origen principal en el grupo de orígenes.
El comportamiento de solicitud y respuesta para el origen principal es igual que un origen que no es un grupo de orígenes. Para obtener más información, consulte [Comportamiento de solicitudes y respuestas para orígenes de Amazon S3](RequestAndResponseBehaviorS3Origin.md) y [Comportamiento de solicitudes y respuestas para orígenes personalizados](RequestAndResponseBehaviorCustomOrigin.md).
A continuación se describe el comportamiento de conmutación por error de origen cuando el origen principal devuelve códigos de estado HTTP específicos:
+ Código de estado HTTP 2xx (éxito): CloudFront almacena en caché el archivo y lo devuelve al lector.
+ Código de estado HTTP 3xx (redirección): CloudFront devuelve el código de estado al lector.
+ Código de estado HTTP 4xx o 5xx (error de cliente/servidor): si el código de estado devuelto se ha configurado para la conmutación por error, CloudFront envía la misma solicitud al origen secundario del grupo de orígenes.
+ Código de estado HTTP 4xx o 5xx (error de cliente/servidor): si el código de estado devuelto no se ha configurado para conmutación por error, CloudFront devuelve el error al lector.
CloudFront conmuta por error al origen secundario solo cuando el método HTTP de la solicitud del lector es `GET`, `HEAD` u `OPTIONS`. CloudFront no realiza una conmutación por error cuando el lector envía un método HTTP diferente (por ejemplo `POST`, `PUT`, etc.).
Cuando CloudFront envía una solicitud a un origen secundario, el comportamiento de respuesta es el mismo que para un origen de CloudFront que no está en un grupo de orígenes.
Para obtener más información acerca de los grupos de orígenes, consulte [Optimización de alta disponibilidad con conmutación por error de origen de CloudFront](high_availability_origin_failover.md).
# Añadido de encabezados personalizados a solicitudes de origen
Puede configurar CloudFront para agregar encabezados personalizados a las solicitudes que envía a su origen. Puede usar encabezados personalizados para enviar y recopilar información de su origen que no obtenga con las solicitudes típicas del lector. Puede incluso personalizar estos encabezados para cada origen. CloudFront admite encabezados personalizados tanto para orígenes personalizados como para orígenes Amazon S3.
**Contents**
+ [Casos de uso](#add-origin-custom-headers-use-cases)
+ [Configuración de CloudFront para agregar encabezados personalizados a solicitudes de origen](#add-origin-custom-headers-configure)
+ [Encabezados personalizados que CloudFront no puede agregar a solicitudes de origen](#add-origin-custom-headers-denylist)
+ [Configuración de CloudFront para reenviar el encabezado de `Authorization`](#add-origin-custom-headers-forward-authorization)
## Casos de uso
Puede utilizar encabezados personalizados, como los siguientes ejemplos:
**Identificación de solicitudes de CloudFront**
Puede identificar las solicitudes que su origen recibe de CloudFront. Esto resulta útil si desea saber si los usuarios están eludiendo CloudFront o si está utilizando más de una CDN y desea obtener información acerca de qué solicitudes provienen de cada CDN.
Si utiliza un origen de Amazon S3 y habilita el [registro de acceso del servidor de Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/dev/ServerLogs.html), los registros no incluyen información del encabezado.
**Determinar qué solicitudes provienen de una distribución en concreto**
Si configura más de una distribución de CloudFront para que utilice el mismo origen, puede agregar distintos encabezados personalizados a cada distribución. A continuación, puede utilizar los registros de su origen para determinar qué solicitudes provenían de cada distribución de CloudFront.
**Habilitar el uso compartido de recursos entre orígenes (CORS)**
Si algunos de sus lectores no admite el uso compartido de recursos entre orígenes (CORS), puede configurar CloudFront para que agregue siempre el encabezado `Origin` a las solicitudes que envía al origen. A continuación, puede configurar su origen para que devuelva el encabezado `Access-Control-Allow-Origin` de cada solicitud. También debe [configurar CloudFront para que respete la configuración de CORS](header-caching.md#header-caching-web-cors).
**Controlar el acceso al contenido**
Puede utilizar encabezados personalizados para controlar el acceso al contenido. Al configurar el origen para que responda a las solicitudes solo cuando incluyan un encabezado personalizado que haya agregado CloudFront, evita que los usuarios eludan CloudFront y obtengan acceso al contenido directamente en el origen. Para obtener más información, consulte [Restricción del acceso a archivos en orígenes personalizados](private-content-overview.md#forward-custom-headers-restrict-access).
## Configuración de CloudFront para agregar encabezados personalizados a solicitudes de origen
Para configurar una distribución para agregar encabezados personalizados a las solicitudes que envía al origen, actualice la configuración de origen mediante uno de los métodos siguientes:
+ **Consola de CloudFront**: al crear o actualizar una distribución, especifique los nombres y los valores de encabezado en la opción **Origin Custom Headers**. Para obtener más información, consulte [Agregar encabezado personalizado](DownloadDistValuesOrigin.md#DownloadDistValuesOriginCustomHeaders).
+ **API de CloudFront**: para cada origen al que desee agregar encabezados personalizados, especifique los nombres y valores del encabezado en el campo `CustomHeaders` dentro de `Origin`. Para obtener más información, consulte [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html) o [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html) en la *Amazon CloudFront API Reference*.
Si los nombres y valores del encabezado que especifica ya no están presentes en la solicitud del lector, CloudFront los agrega a la solicitud de origen. Si hay un encabezado, CloudFront sobrescribe el valor de encabezado antes de reenviar la solicitud al origen.
Para ver las cuotas que se aplican a los encabezados personalizados de origen, consulte [Cuotas en encabezados](cloudfront-limits.md#limits-custom-headers).
## Encabezados personalizados que CloudFront no puede agregar a solicitudes de origen
No puede configurar CloudFront para que agregue ninguno de los encabezados siguientes a las solicitudes que envía a su origen:
+ `Cache-Control`
+ `Connection`
+ `Content-Length`
+ `Cookie`
+ `Host`
+ `If-Match`
+ `If-Modified-Since`
+ `If-None-Match`
+ `If-Range`
+ `If-Unmodified-Since`
+ `Max-Forwards`
+ `Pragma`
+ `Proxy-Authenticate`
+ `Proxy-Authorization`
+ `Proxy-Connection`
+ `Range`
+ `Request-Range`
+ `TE`
+ `Trailer`
+ `Transfer-Encoding`
+ `Upgrade`
+ `Via`
+ Encabezados que comiencen por `X-Amz-`
+ Encabezados que comiencen por `X-Edge-`
+ `X-Real-Ip`
## Configuración de CloudFront para reenviar el encabezado de `Authorization`
Cuando CloudFront reenvía una solicitud del lector a su origen, CloudFront elimina algunos encabezados de lector de forma predeterminada, incluido el encabezado `Authorization`. Para asegurarse de que su origen siempre recibe el encabezado `Authorization` en las solicitudes de origen, tiene las siguientes opciones:
+ Agregue el encabezado `Authorization` a la clave de caché mediante una política de caché. Todos los encabezados de la clave de caché se incluyen automáticamente en las solicitudes de origen. Para obtener más información, consulte [Control de la clave de caché con una política](controlling-the-cache-key.md).
+ Utilice una política de solicitud de origen que reenvíe todos los encabezados del lector al origen. No puede reenviar el encabezado `Authorization` individualmente en una política de solicitud de origen, pero cuando reenvíe todos los encabezados del lector CloudFront incluye el encabezado `Authorization` en las solicitudes de lector. CloudFront proporciona una política de solicitud de origen administrada para este caso de uso, denominada **Managed-AllViewer**. Para obtener más información, consulte [Uso de políticas de solicitudes de origen administradas](using-managed-origin-request-policies.md).
# Cómo CloudFront procesa las solicitudes parciales de un objeto (rango GET)
Para objetos grandes, es posible que los lectores (navegadores web u otros clientes) realicen varias solicitudes `GET` y utilicen el encabezado de solicitud `Range` para descargar el objeto en partes más pequeñas. Estas solicitudes de rangos de bytes, a veces conocidas como solicitudes `Range GET`, mejoran la eficacia de las descargas parciales y la recuperación de transferencias que hayan fallado parcialmente.
Cuando CloudFront recibe una solicitud `Range GET`, revisa la caché de la ubicación periférica que recibe la solicitud. Si la caché de dicha ubicación periférica ya contiene todo el objeto o la parte solicitada del objeto, CloudFront envía inmediatamente el rango solicitado desde la caché.
Si la caché no contiene el rango solicitado, CloudFront reenvía la solicitud al origen. (Para optimizar el rendimiento, CloudFront puede solicitar un intervalo superior al solicitado en `Range GET`.) Lo que ocurre a continuación depende de si el origen admite solicitudes `Range GET`:
+ **Si el origen admite solicitudes `Range GET`**: devuelve el intervalo solicitado. CloudFront sirve el intervalo solicitado y lo almacena en la caché para futuras solicitudes. (Amazon S3 admite solicitudes `Range GET`, al igual que muchos servidores HTTP).
+ **Si el origen no admite solicitudes `Range GET`:** devuelve todo el objeto. CloudFront sirve la solicitud actual enviando todo el objeto almacenándolo también en caché para futuras solicitudes. Después de que CloudFront almacene en caché todo el objeto en una caché perimetral, responde a las nuevas solicitudes `Range GET` enviando el intervalo solicitado.
En cualquier caso, CloudFront comienza a enviar el intervalo o el objeto solicitado al usuario final en cuanto llega el primer byte del origen.
**nota**
Si un lector envía una solicitud `Range GET` y el origen devuelve `Transfer-Encoding: chunked`, CloudFront devuelve el objeto entero al lector en lugar del intervalo solicitado.
Por lo general, CloudFront sigue la especificación RFC en el encabezado `Range`. Sin embargo, si sus encabezados `Range` no cumplen con los siguientes requisitos, CloudFront devuelve el código de estado HTTP `200` con el objeto entero en lugar del código de estado `206` con los intervalos especificados:
+ Los rangos deben publicarse en orden ascendente. Por ejemplo, `100-200,300-400` es válido; `300-400,100-200` no es válido.
+ Los rangos no deben superponerse. Por ejemplo, `100-200,150-250` no es válido.
+ Todas las especificaciones de los rangos deben ser válidas. Por ejemplo, no puede especificar valores negativos como parte de un rango.
Para obtener más información sobre el encabezado de solicitud `Range`, consulte[Range Requests](https://httpwg.org/specs/rfc7233.html#range.requests) en RFC 7233, o [Range](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Range) en MDN Web Docs.
## Uso de solicitudes de rango para almacenar en caché objetos grandes
Cuando el almacenamiento en caché está habilitado, CloudFront no recupera ni almacena en caché un objeto de más de 50 GB. Cuando un origen indica que el objeto es mayor que este tamaño (en el encabezado de respuesta `Content-Length`), CloudFront cierra la conexión con el origen y devuelve un error al lector. (Con el almacenamiento en caché desactivado, CloudFront puede recuperar un objeto mayor que este tamaño del origen y pasarlo al lector. Sin embargo, CloudFront no almacena en caché el objeto).
Sin embargo, con las solicitudes de rango, puede utilizar CloudFront para almacenar en caché un objeto mayor que el [tamaño máximo de archivo almacenable en caché](cloudfront-limits.md#limits-web-distributions).
**Example Ejemplo**
1. Considere un origen con un objeto de 100 GB. Cuando el almacenamiento en caché está habilitado, CloudFront no recupera ni almacena en caché un objeto de este tamaño. Sin embargo, el lector puede enviar varias solicitudes de rango para recuperar este objeto en partes, con cada parte menor que 50 GB.
1. El lector puede solicitar el objeto en partes de 20 GB mediante el envío de una solicitud con el encabezado `Range: bytes=0-21474836480` para recuperar la primera parte, otra solicitud con el encabezado `Range: bytes=21474836481-42949672960` para recuperar la siguiente parte, y así sucesivamente.
1. Cuando el lector ha recibido todas las partes, puede combinarlas para construir el objeto original de 100 GB.
1. En este caso, CloudFront almacena en caché cada una de las partes de 20 GB del objeto y puede responder a las solicitudes posteriores de la misma parte desde la caché.
Para una solicitud de rango para un objeto comprimido, la solicitud de rango de bytes se basa en el tamaño comprimido y no en el tamaño original del objeto. Para obtener más información acerca de la compresión de archivos, consulte [Ofrecimiento de archivos comprimidos](ServingCompressedFiles.md).
# Cómo CloudFront procesa los códigos de estado HTTP 3xx desde el origen
Cuando CloudFront solicita un objeto desde su bucket de Amazon S3 o el servidor de origen personalizado, su origen a veces devuelve un código de estado HTTP 3xx. Esto suele indicar una de las siguientes posibilidades:
+ La dirección URL del objeto ha cambiado (por ejemplo, códigos de estado 301, 302, 307 o 308)
+ El objeto no ha cambiado desde la última vez que CloudFront lo solicitó (código de estado 304)
CloudFront almacena en caché las respuestas 3xx de acuerdo con la configuración de su distribución de CloudFront y los encabezados de la respuesta. CloudFront almacena en caché las respuestas 307 y 308 solo cuando incluye el encabezado `Cache-Control` en las respuestas del origen. Para obtener más información, consulte [Administración de cuánto tiempo se mantiene el contenido en una caché (vencimiento)](Expiration.md).
Si su origen devuelve un código de estado de redireccionamiento (por ejemplo, 301 o 307), CloudFront no sigue el redireccionamiento. CloudFront pasa la respuesta 301 o 307 al lector, que puede seguir el redireccionamiento enviando una nueva solicitud.
# Procesamiento de CloudFront de los códigos de estado HTTP 4xx y 5xx desde el origen
Cuando CloudFront solicita un objeto desde su bucket de Amazon S3 o un servidor de origen personalizado, el origen a veces devuelve un código de estado HTTP 4xx o 5xx, que indica que se ha producido un error. El comportamiento de CloudFront depende de:
+ Si ha configurado páginas de error personalizadas
+ Si ha configurado el tiempo durante el que desea que CloudFront almacene en caché las respuestas de error de su origen (TTL mínimo de almacenamiento de errores en la caché)
+ El código del estado
+ En el caso de códigos de estado 5xx, si el objeto solicitado se encuentra en la caché perimetral de CloudFront
+ Para algunos códigos de estado 4xx, si el origen devuelve un encabezado `Cache-Control max-age` o `Cache-Control s-maxage`
CloudFront siempre almacena en caché las respuestas a las solicitudes `GET` y `HEAD`. También puede configurar CloudFront para almacenar en caché las respuestas a solicitudes `OPTIONS`. CloudFront no almacena en caché las respuestas a las solicitudes que utilizan los otros métodos.
Si el origen no responde, la solicitud de CloudFront al origen agota el tiempo de espera, lo que se considera un error HTTP 5xx del origen, aunque el origen no haya respondido con ese error. En ese caso, CloudFront sigue ofreciendo contenido almacenado en caché. Para obtener más información, consulte [Origen no disponible](RequestAndResponseBehaviorCustomOrigin.md#ResponseCustomOriginUnavailable).
Si ha activado el registro, CloudFront escribe los resultados en registros independientemente del código de estado HTTP.
Para obtener más información acerca de las características y las opciones relacionadas con el mensaje de error devuelto por CloudFront, consulte lo siguiente:
+ Para obtener más información acerca de la configuración de páginas de error personalizadas desde la consola de CloudFront, consulte [Páginas de error personalizadas y almacenamiento de errores en caché](DownloadDistValuesErrorPages.md).
+ Para obtener información acerca del TTL mínimo de almacenamiento de errores en la caché desde la consola de CloudFront, consulte [TTL mínimo de almacenamiento de errores en caché (segundos)](DownloadDistValuesErrorPages.md#DownloadDistValuesErrorCachingMinTTL).
+ Para obtener una lista de los códigos de estado HTTP que CloudFront almacena en caché, consulte [Códigos de estado HTTP 4xx y 5xx que CloudFront almacena en caché](#HTTPStatusCodes-cached-errors).
**Topics**
+ [Cómo CloudFront procesa los errores cuando las páginas de error personalizadas están configuradas](#HTTPStatusCodes-custom-error-pages)
+ [Cómo CloudFront procesa los errores si no ha configurado las páginas de error personalizadas](#HTTPStatusCodes-no-custom-error-pages)
+ [Códigos de estado HTTP 4xx y 5xx que CloudFront almacena en caché](#HTTPStatusCodes-cached-errors)
## Cómo CloudFront procesa los errores cuando las páginas de error personalizadas están configuradas
Si ha configurado páginas de error personalizadas, el comportamiento de CloudFront dependerá de si el objeto solicitado está o no en la caché perimetral.
### El objeto solicitado no está en la caché perimetral
CloudFront continúa intentando obtener el objeto solicitado de su origen si se cumplen todas las condiciones que se indican a continuación:
+ Un espectador solicita un objeto.
+ El objeto no está en la caché perimetral.
+ Su origen devuelve un código de estado HTTP 4xx o 5xx y se cumple alguna de las condiciones siguientes:
+ Su origen devuelve un código de estado HTTP 5xx en lugar de devolver un código 304 (No modificado) o una versión actualizada del objeto.
+ Su origen devuelve un código de estado HTTP 4xx que no está restringido por un encabezado de control de la caché y está incluido en la siguiente lista de códigos de estado: [Códigos de estado HTTP 4xx y 5xx que CloudFront almacena en caché](#HTTPStatusCodes-cached-errors).
+ El origen devuelve un código de estado HTTP 4xx con un encabezado `Cache-Control max-age` o un encabezado `Cache-Control s-maxage` y el código de estado está incluido en la siguiente lista de códigos de estado: Control [Códigos de estado HTTP 4xx que CloudFront almacena en caché en función de los encabezados `Cache-Control`](#HTTPStatusCodes-cached-errors-with-cache-control).
**CloudFront hace lo siguiente:**
1. En la caché perimetral de CloudFront que recibió la solicitud del lector, CloudFront comprueba la configuración de la distribución y obtiene la ruta de la página de error personalizada que corresponde al código de estado devuelto por su origen.
1. CloudFront comprueba el primer comportamiento de la caché de la distribución que tenga un patrón de ruta que coincida con la ruta de la página de error personalizada.
1. La ubicación periférica de CloudFront envía una solicitud de la página de error personalizada al origen especificado en el comportamiento de la caché.
1. El origen devuelve la página de error personalizada a la ubicación periférica.
1. CloudFront devuelve la página de error personalizada al lector que ha realizado la solicitud y almacena en caché dicha página durante el tiempo máximo siguiente:
+ La cantidad de tiempo especificado por el TTL mínimo de almacenamiento en caché de errores (10 segundos de forma predeterminada)
+ El periodo de tiempo especificado por un encabezado `Cache-Control max-age` o un encabezado `Cache-Control s-maxage` que devuelve el origen cuando la primera solicitud generó el error
1. Una vez transcurrido el tiempo de almacenamiento en caché (determinado en el paso 5), CloudFront intenta de nuevo obtener el objeto solicitado reenviando otra solicitud a su origen. CloudFront continúa intentándolo a intervalos especificados por el TTL mínimo de almacenamiento de errores en caché.
**nota**
Si también configuró un comportamiento de caché para la misma página de error personalizada, CloudFront utiliza el TTL del comportamiento de caché en su lugar. En este caso, CloudFront hará lo siguiente en los pasos 5 y 6:
Después de que CloudFront devuelva la página de error personalizada al espectador que realizó la solicitud, CloudFront verifica el TTL del comportamiento de caché (por ejemplo, si configuró el TTL predeterminado en 5 segundos). A continuación, CloudFront almacena en caché la página de error personalizada hasta ese máximo.
Después de transcurrir 5 segundos, CloudFront recupera la página de error personalizada del origen nuevamente. CloudFront continuará intentándolo a intervalos especificados por el TTL de comportamiento de almacenamiento en caché.
Para obtener más información, consulte la [configuración de TTL](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMinTTL) de comportamiento de la caché.
### El objeto solicitado está en la caché perimetral
CloudFront continúa sirviendo el objeto que se encuentra en ese momento en la caché perimetral si se cumplen todas las condiciones que se indican a continuación:
+ Un espectador solicita un objeto.
+ El objeto se encuentra en la memoria caché de borde, pero ha caducado
+ Su origen devuelve un código de estado HTTP 5xx en lugar de devolver un código 304 (No modificado) o una versión actualizada del objeto.
**CloudFront hace lo siguiente:**
1. Si el origen devuelve un código de estado 5xx, CloudFront sirve el objeto a pesar de que haya caducado. Durante el TTL mínimo de almacenamiento de errores en caché, CloudFront continúa respondiendo a las solicitudes de los lectores ofreciendo el objeto de la caché perimetral.
Si el origen devuelve un código de estado 4xx, CloudFront devuelve el código de estado al lector en lugar del objeto solicitado.
1. Una vez finalizado el TTL mínimo de almacenamiento de errores en caché, CloudFront intenta obtener el objeto solicitado una vez más reenviando otra solicitud al origen. Tenga en cuenta que si el objeto no se solicita con frecuencia, CloudFront podría desalojarlo de la caché perimetral mientras el servidor de origen sigue devolviendo respuestas 5xx. Para obtener más información acerca de por cuánto tiempo pueden permanecer los objetos en las cachés perimetrales de CloudFront, consulte [Administración de cuánto tiempo se mantiene el contenido en una caché (vencimiento)](Expiration.md).
## Cómo CloudFront procesa los errores si no ha configurado las páginas de error personalizadas
Si no ha configurado páginas de error personalizadas, el comportamiento de CloudFront dependerá de si el objeto solicitado está o no en la caché perimetral.
**Topics**
+ [El objeto solicitado no está en la caché perimetral](#HTTPStatusCodes-no-custom-error-pages-not-in-cache)
+ [El objeto solicitado está en la caché perimetral](#HTTPStatusCodes-no-custom-error-pages-in-cache)
### El objeto solicitado no está en la caché perimetral
CloudFront continúa intentando obtener el objeto solicitado de su origen si se cumplen todas las condiciones que se indican a continuación:
+ Un espectador solicita un objeto.
+ El objeto no está en la caché perimetral.
+ Su origen devuelve un código de estado HTTP 4xx o 5xx y se cumple alguna de las condiciones siguientes:
+ Su origen devuelve un código de estado HTTP 5xx en lugar de devolver un código 304 (No modificado) o una versión actualizada del objeto.
+ Su origen devuelve un código de estado HTTP 4xx que no está restringido por un encabezado de control de la caché y está incluido en la siguiente lista de códigos de estado: [Códigos de estado HTTP 4xx y 5xx que CloudFront almacena en caché](#HTTPStatusCodes-cached-errors)
+ El origen devuelve un código de estado HTTP 4xx con un encabezado `Cache-Control max-age` o un encabezado `Cache-Control s-maxage` y el código de estado está incluido en la siguiente lista de códigos de estado: Control [Códigos de estado HTTP 4xx que CloudFront almacena en caché en función de los encabezados `Cache-Control`](#HTTPStatusCodes-cached-errors-with-cache-control).
CloudFront hace lo siguiente:
1. CloudFront devuelve un código de estado 4xx o 5xx al lector y también almacena el código de estado en la caché perimetral que recibió la solicitud durante el tiempo máximo siguiente:
+ La cantidad de tiempo especificado por el TTL mínimo de almacenamiento en caché de errores (10 segundos de forma predeterminada)
+ El periodo de tiempo especificado por un encabezado `Cache-Control max-age` o un encabezado `Cache-Control s-maxage` que devuelve el origen cuando la primera solicitud generó el error
1. Para la duración del tiempo de almacenamiento en caché (determinado en el paso 1), CloudFront responde a las solicitudes de los lectores posteriores del mismo objeto con el código de estado almacenado en caché 4xx o 5xx.
1. Una vez transcurrido el tiempo de almacenamiento en caché (determinado en el paso 1), CloudFront intenta de nuevo obtener el objeto solicitado reenviando otra solicitud a su origen. CloudFront continúa intentándolo a intervalos especificados por el TTL mínimo de almacenamiento de errores en caché.
### El objeto solicitado está en la caché perimetral
CloudFront continúa sirviendo el objeto que se encuentra en ese momento en la caché perimetral si se cumplen todas las condiciones que se indican a continuación:
+ Un espectador solicita un objeto.
+ El objeto se encuentra en la memoria caché de borde, pero ha caducado Esto significa que el objeto está *obsoleto*.
+ Su origen devuelve un código de estado HTTP 5xx en lugar de devolver un código 304 (No modificado) o una versión actualizada del objeto.
CloudFront hace lo siguiente:
1. Si el origen devuelve un código de error 5xx, CloudFront sirve el objeto a pesar de que haya caducado. Durante la vigencia del TTL mínimo de almacenamiento en caché de errores (10 segundos de forma predeterminada), CloudFront continúa respondiendo a las solicitudes de los lectores sirviendo el objeto de la caché perimetral.
Si el origen devuelve un código de estado 4xx, CloudFront devuelve el código de estado al lector en lugar del objeto solicitado.
1. Una vez finalizado el TTL mínimo de almacenamiento de errores en caché, CloudFront intenta obtener el objeto solicitado una vez más reenviando otra solicitud al origen. Si el objeto no se solicita con frecuencia, CloudFront podría desalojarlo de la caché perimetral mientras el servidor de origen sigue devolviendo respuestas 5xx. Para obtener más información, consulte [Administración de cuánto tiempo se mantiene el contenido en una caché (vencimiento)](Expiration.md).
**sugerencia**
Si configura la directiva `stale-if-error` o `Stale-While-Revalidate`, puede especificar durante cuánto tiempo estarán disponibles los objetos obsoletos en la caché perimetral. Esto le permite seguir ofreciendo contenido a los lectores incluso cuando su origen no esté disponible. Para obtener más información, consulte [Distribución de contenido obsoleto (caducado)](Expiration.md#stale-content).
CloudFront solo servirá un objeto que esté obsoleto hasta el valor [TTL máximo](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMaxTTL) especificado. Después de este tiempo, el objeto no estará disponible desde la caché perimetral.
## Códigos de estado HTTP 4xx y 5xx que CloudFront almacena en caché
CloudFront almacena en caché códigos de estado HTTP 4xx y 5xx devueltos por su origen, en función del código de estado específico que se devuelve y de si el origen devuelve encabezados específicos en la respuesta.
CloudFront almacena en caché los siguientes códigos de estado HTTP 4xx y 5xx devueltos por el origen. Si ha configurado una página de error personalizada para un código de estado HTTP, CloudFront la almacena en caché.
**nota**
Si utiliza la política de caché administrada por [CachingDisabled](using-managed-cache-policies.md#managed-cache-policy-caching-disabled), CloudFront no almacenará en caché estos códigos de estado ni las páginas de error personalizadas.
| | |
| --- |--- |
| 404 | no encontrado |
| 414 | URI de solicitud demasiado grande |
| 500 | Internal Server Error |
| 501 | No implementado |
| 502 | Puerta de enlace incorrecta |
| 503 | Servicio no disponible |
| 504 | Tiempo de espera de puerta de enlace agotado |
### Códigos de estado HTTP 4xx que CloudFront almacena en caché en función de los encabezados `Cache-Control`
CloudFront solo almacena en caché los siguientes códigos de estado HTTP 4xx devueltos por el origen si el origen devuelve un encabezado `Cache-Control max-age` o `Cache-Control s-maxage`. Si ha configurado una página de error personalizada para uno de estos códigos de estado HTTP, y el origen devuelve uno de los encabezados de control de la caché, CloudFront la almacena en caché.
| | |
| --- |--- |
| 400 | solicitud errónea |
| 403 | Prohibido |
| 405 | método no permitido |
| 412¹ | Condición previa con error |
| 415¹ | Tipo de medio incompatible |
¹ CloudFront no admite la creación de páginas de error personalizadas para estos códigos de estado HTTP.
# Generación de respuestas de error personalizadas
Si un objetos que ofrece a través de CloudFront no está disponible por algún motivo, el servidor web suele devolver un código de estado HTTP a CloudFront. Por ejemplo, si un lector especifica una URL no válida, el servidor web devuelve un código de estado HTTP 404 (no encontrado) a CloudFront y CloudFront se lo devuelve al lector. En lugar de utilizar esta respuesta de error predeterminada, puede crear una respuesta personalizada que CloudFront devuelva al lector.
Si configura CloudFront para devolver una página de error personalizada para un código de estado HTTP pero la página de error personalizada no está disponible, CloudFront devuelve al lector el código de estado que CloudFront recibió del origen que contiene las páginas de error personalizadas. Por ejemplo, supongamos que el origen personalizado devuelve un código de estado 500 y que haya configurado CloudFront para obtener de un bucket de Amazon S3 una página de error personalizada para un código de estado 500. Sin embargo, alguien ha eliminado accidentalmente la página de error personalizada del bucket de Amazon S3. CloudFront devolverá un código de estado HTTP 404 (no encontrado) al lector que solicitó el objeto.
Cuando CloudFront devuelve una página de error personalizada a un lector, paga los cargos estándar de CloudFront por la página de error personalizada, no paga cargos por el objeto solicitado. Para obtener más información acerca de los cargos de CloudFront, consulte [Precios de Amazon CloudFront](https://aws.amazon.com/cloudfront/pricing/).
**Topics**
+ [Configuración del comportamiento de respuestas de error](custom-error-pages-procedure.md)
+ [Creación de una página de error personalizada para códigos de estado HTTP específicos](creating-custom-error-pages.md)
+ [Almacenamiento de objetos y páginas de error personalizadas en diferentes lugares](custom-error-pages-different-locations.md)
+ [Cambio de códigos de respuesta devueltos por CloudFront](custom-error-pages-response-code.md)
+ [Control de cuánto tiempo CloudFront almacena los errores en caché](custom-error-pages-expiration.md)
# Configuración del comportamiento de respuestas de error
Tiene varias opciones para administrar cómo responde CloudFront cuando hay un error. Para configurar respuestas de errores personalizadas, puede utilizar la consola o la API de CloudFront o CloudFormation. Independientemente de cómo elija actualizar la configuración, tenga en cuenta las siguientes sugerencias y recomendaciones:
+ Guarde las páginas de error personalizadas en una ubicación accesible para CloudFront. Le recomendamos que las almacene en un bucket de Amazon S3 y que [no las almacene en el mismo lugar que el resto del contenido de su sitio web o aplicación](custom-error-pages-different-locations.md). Si almacena las páginas de error personalizadas en el mismo origen que su sitio web o aplicación y el origen comienza a devolver errores 5xx, CloudFront no puede obtener las páginas de error personalizadas porque el servidor de origen no está disponible. Para obtener más información, consulte [Almacenamiento de objetos y páginas de error personalizadas en diferentes lugares](custom-error-pages-different-locations.md).
+ Asegúrese de que CloudFront tenga permiso para obtener sus páginas de error personalizadas. Si las páginas de error personalizadas se almacenan en Amazon S3, deben ser accesibles públicamente o debe configurar un [control de acceso de origen (OAC)](private-content-restricting-access-to-s3.md) de CloudFront. Si las páginas de error personalizadas se almacenan en un origen personalizado, deben ser accesibles públicamente.
+ (Opcional) Configure su origen para agregar un encabezado `Cache-Control` o `Expires` junto con las páginas de error personalizadas, si lo desea. También puede utilizar la configuración **TTL mínimo de almacenamiento de errores en caché** para controlar cuánto tiempo CloudFront almacena en caché las páginas de error personalizadas. Para obtener más información, consulte [Control de cuánto tiempo CloudFront almacena los errores en caché](custom-error-pages-expiration.md).
## Configuración de respuestas de error personalizadas
Para configurar respuestas de error personalizadas en la consola de CloudFront, debe tener una distribución de CloudFront. En la consola, la configuración de las respuestas de error personalizadas solo está disponible para distribuciones existentes. Para obtener información sobre cómo crear una distribución, consulte [Introducción a una distribución estándar de CloudFront](GettingStarted.SimpleDistribution.md).
------
#### [ Console ]
**Para configurar respuestas de error personalizadas (consola)**
1. Inicie sesión en la Consola de administración de AWS y abra la página **Distributions (Distribuciones)** en la consola de CloudFront en [https://console.aws.amazon.com/cloudfront/v4/home#distributions](https://console.aws.amazon.com/cloudfront/v4/home#distributions).
1. En la lista de distribuciones, elija la distribución que desea actualizar.
1. Elija la pestaña **Error Pages** (Páginas de error) y, a continuación, elija **Create Custom Error Response** (Crear respuesta de error personalizada).
1. Ingrese los valores aplicables. Para obtener más información, consulte [Páginas de error personalizadas y almacenamiento de errores en caché](DownloadDistValuesErrorPages.md).
1. Después de introducir los valores deseados, elija **Create** (Crear).
------
#### [ CloudFront API or CloudFormation ]
Para configurar respuestas de error personalizadas con la API de CloudFront o la CloudFormation, utilice el tipo `CustomErrorResponse` en una distribución. Para obtener más información, consulte los siguientes temas:
+ [AWS::CloudFront::Distribution CustomErrorResponse](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cloudfront-distribution-customerrorresponse.html) en la *Guía del usuario de AWS CloudFormation*
+ [CustomErrorResponse](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CustomErrorResponse.html) en la *Referencia de la API de Amazon CloudFront*
------
# Creación de una página de error personalizada para códigos de estado HTTP específicos
Si prefiere mostrar un mensaje de error personalizado en lugar del mensaje predeterminado (por ejemplo, una página que utiliza el mismo formato que el resto del sitio web), puede hacer que CloudFront devuelva al lector un objeto (por ejemplo, un archivo HTML) que contenga el mensaje de error personalizado.
Para especificar el archivo que desea devolver y los errores por los que se debe devolver este archivo, debe actualizar la distribución de CloudFront y especificar esos valores. Para obtener más información, consulte [Configuración del comportamiento de respuestas de error](custom-error-pages-procedure.md).
Por ejemplo, la siguiente es una página de error personalizada:
![\[Captura de pantalla de un ejemplo de página 404 de AWS personalizada.\]](http://docs.aws.amazon.com/es_es/AmazonCloudFront/latest/DeveloperGuide/images/custom-error-page-aws-404-example.png)
Puede especificar un objeto diferente por código de estado HTTP admitido o el mismo objeto para todos los códigos de estado admitidos. Puede elegir especificar páginas de error personalizadas para algunos códigos de estado y no para otros.
Los objetos que ofrece a través de CloudFront pueden no estar disponibles por diversas razones. Estas se dividen en dos amplias categorías:
+ *Errores de cliente*, que indican un problema con la solicitud. Por ejemplo, un objeto con el nombre especificado no está disponible o el usuario no tiene los permisos necesarios para obtener un objeto en el bucket de Amazon S3. Cuando se produce un error de cliente, el origen devuelve a CloudFront un código de estado HTTP en el intervalo de los 4xx.
+ *Errores de servidor*, que indican un problema con el servidor de origen. Por ejemplo, el servidor HTTP está ocupado o no disponible. Cuando se produce un error de servidor, el servidor de origen devuelve a CloudFront un código de estado HTTP en el intervalo de los 5xx o CloudFront no obtiene respuesta del servidor de origen durante un periodo determinado y supone un código de estado 504 (tiempo de espera de gateway agotado).
Los códigos de estado HTTP para los que CloudFront puede devolver una página de error personalizada son:
+ 400, 403, 404, 405, 414, 416
+ 500, 501, 502, 503, 504
**Notas**
Si CloudFront detecta que la solicitud puede no ser segura, devuelve un error 400 (Solicitud incorrecta) en lugar de una página de error personalizada.
Puede crear una página de error personalizada para el código de estado HTTP 416 (Intervalo solicitado no puede ser satisfecho) y puede cambiar el código de estado HTTP que CloudFront proporciona a los lectores cuando el origen devuelve un código de estado 416 a CloudFront. Para obtener más información, consulte [Cambio de códigos de respuesta devueltos por CloudFront](custom-error-pages-response-code.md). Sin embargo, CloudFront no almacena en caché las respuestas de los códigos de estado 416, así que, aunque especifique un valor para **Error Caching Minimum TTL** (TTL mínimo de almacenamiento de errores en caché) para el código de estado 416, CloudFront no lo utiliza.
En algunos casos, CloudFront no devuelve una página de error personalizada para el código de estado HTTP 503, incluso si configura CloudFront para hacerlo. Si el código de error de CloudFront es `Capacity Exceeded` o `Limit Exceeded`, CloudFront devuelve un código de estado 503 al lector sin utilizar la página de error personalizada.
Si ha creado una página de error personalizada, CloudFront devolverá `Connection: close` o `Connection: keep-alive` para los siguientes códigos de respuesta:
CloudFront devuelve `Connection: close` para los códigos de estado: 400, 405, 414, 416, 500 y 501
CloudFront devuelve `Connection: keep-alive` para los códigos de estado 403, 404, 502, 503 y 504
Para obtener una explicación detallada acerca de cómo CloudFront gestiona las respuestas de error del origen, consulte [Procesamiento de CloudFront de los códigos de estado HTTP 4xx y 5xx desde el origen](HTTPStatusCodes.md).
# Almacenamiento de objetos y páginas de error personalizadas en diferentes lugares
Si desea almacenar los objetos y las páginas de error personalizadas en diferentes ubicaciones, la distribución debe incluir un comportamiento de la caché que cumpla con las siguientes condiciones:
+ El valor de **Path Pattern (Patrón de ruta)** debe coincidir con la ruta de los mensajes de error personalizados. Por ejemplo, supongamos que ha guardado páginas para errores 4xx personalizadas en un bucket de Amazon S3 en un directorio llamado `/4xx-errors`. La distribución debe incluir un comportamiento de la caché cuyo patrón de ruta dirija las solicitudes de las páginas de error personalizadas a esa ubicación, por ejemplo, `/4xx-errors/*`.
+ El valor de **Origin (Origen)** especifica el valor de **Origin ID (ID de origen)** del origen que contiene las páginas de error personalizadas.
Para obtener más información, consulte [Configuración del comportamiento de la caché](DownloadDistValuesCacheBehavior.md).
# Cambio de códigos de respuesta devueltos por CloudFront
Puede configurar CloudFront para que devuelva al lector un código de estado HTTP diferente al que CloudFront recibió del origen. Por ejemplo, si el origen devuelve un código de estado 500 a CloudFront, es posible que desee que CloudFront devuelva una página de error personalizada y un código de estado 200 (OK) al lector. Existen diversas razones por las que puede querer que CloudFront devuelva al lector un código de estado diferente del que el origen ha devuelto a CloudFront:
+ Algunos dispositivos de Internet (algunos firewalls y proxis corporativos, por ejemplo) interceptan los códigos de estado HTTP 4xx y 5xx y evitan que la respuesta se devuelva al lector. En este escenario, si sustituye `200`, la respuesta no se intercepta.
+ Si no le resulta especialmente importante distinguir entre diferentes errores de servidor y de cliente, puede especificar `400` o `500` como el valor que CloudFront devuelve para todos los códigos de estado 4xx o 5xx.
+ Quizá desee devolver un código de estado `200` (OK) y un sitio web estático para que sus clientes no sepan que su sitio web está caído.
Si habilita los [registros estándar de CloudFront](AccessLogs.md) y configura CloudFront para cambiar el código de estado HTTP en la respuesta, el valor de la columna `sc-status` de los registros contiene el código de estado que se especifique. Sin embargo, el valor de la columna `x-edge-result-type` no se ve afectado. Contiene el tipo de resultado de la respuesta del origen. Por ejemplo: supongamos que configura CloudFront para devolver un código de estado de `200` al espectador cuando el origen devuelve `404` (No encontrado) a CloudFront. Cuando el origen responda a una solicitud con un código de estado `404`, el valor de la columna `sc-status` en el registro será `200`, pero el valor de la columna `x-edge-result-type` será `Error`.
Puede configurar CloudFront para devolver cualquiera de los siguientes códigos de estado HTTP junto con una página de error personalizada:
+ 200
+ 400, 403, 404, 405, 414, 416
+ 500, 501, 502, 503, 504
# Control de cuánto tiempo CloudFront almacena los errores en caché
CloudFront almacena en caché las respuestas de error durante una duración predeterminada de 10 segundos. A continuación, CloudFront envía la siguiente solicitud para el objeto al origen para ver si el problema que causó el error se ha resuelto y el objeto solicitado está disponible.
Puede especificar la duración de almacenamiento en caché de errores (**Error Caching Minimum TTL [TTL mínimo de almacenamiento de errores en caché])** para cada código de estado 4xx y 5xx que CloudFront almacena en las caché. (Para obtener más información, consulte ). [Códigos de estado HTTP 4xx y 5xx que CloudFront almacena en caché](HTTPStatusCodes.md#HTTPStatusCodes-cached-errors).) Al especificar una duración, tenga en cuenta lo siguiente:
+ Si se especifica una duración breve de almacenamiento de errores en caché, CloudFront reenvía más solicitudes al origen que si se especifica una mayor duración. En el caso de errores 5xx, esto podría agravar el problema que causó el origen para devolver un error.
+ Cuando el origen devuelve un error por un objeto, CloudFront responde a las solicitudes de dicho objeto con la respuesta de error o con la página de error personalizada hasta que finaliza la duración de almacenamiento de errores en caché. Si especifica una duración de almacenamiento de errores en caché mayor, es posible que CloudFront continúe respondiendo a las solicitudes con una respuesta de error o la página de error personalizada durante mucho tiempo después de que el objeto vuelva a estar disponible.
**nota**
Puede crear una página de error personalizada para el código de estado HTTP 416 (Intervalo solicitado no puede ser satisfecho) y puede cambiar el código de estado HTTP que CloudFront proporciona a los lectores cuando el origen devuelve un código de estado 416 a CloudFront. (Para obtener más información, consulte [Cambio de códigos de respuesta devueltos por CloudFront](custom-error-pages-response-code.md).) Sin embargo, CloudFront no almacena en caché las respuestas de los códigos de estado 416, así que, aunque especifique un valor para **Error Caching Minimum TTL** (TTL mínimo de almacenamiento de errores en caché) para el código de estado 416, CloudFront no lo utiliza.
Si desea controlar el tiempo durante el cual CloudFront almacena errores para objetos individuales en la caché, puede configurar el servidor de origen para añadir el encabezado aplicable a la respuesta de error para dicho objeto.
Si el origen añade una directiva `Cache-Control: max-age` o `Cache-Control: s-maxage`, o un encabezado `Expires`, CloudFront almacena en caché respuestas de error para el valor mayor en el encabezado o el valor de **Error Caching Minimum TTL** (TTL mínimo de almacenamiento de errores en caché).
**nota**
Los valores `Cache-Control: max-age` y `Cache-Control: s-maxage` no pueden ser mayores que el valor de **Maximum TTL** (TTL máximo) definido para el comportamiento de la caché para el que se está obteniendo la página de error.
Si el origen agrega una directiva `Cache-Control: no-store`, `Cache-Control: no-cache` o `Cache-Control: private` para los códigos de error 404, 410, 414 o 501, CloudFront no almacena en caché la respuesta de error. Para todos los demás códigos de error, CloudFront ignora las directivas `no-store`, `no-cache` y `private`, y almacena en caché la respuesta de error con el valor del **TTL mínimo de almacenamiento en caché de errores**.
Si el origen añade otras directivas `Cache-Control` o no añade encabezados, CloudFront almacena en caché respuestas de error para el valor de **Error Caching Minimum TTL** (TTL mínimo de almacenamiento de errores en caché).
Si la fecha de vencimiento de un código de estado 4xx o 5xx de un objeto es más lejana de lo que desea y el objeto está disponible nuevamente, puede invalidar el código de error almacenado en caché utilizando la URL del objeto solicitado. Si el origen devuelve una respuesta de error para varios objetos, es necesario invalidar cada uno de los objetos por separado. Para obtener más información acerca de las invalidaciones de objetos, consulte [Invalidación de archivos para eliminar el contenido](Invalidation.md).
Si tiene habilitado el almacenamiento en caché para un origen de bucket de S3 y configura un error que almacena en caché el TTL mínimo de 0 segundos en su distribución de CloudFront, seguirá apareciendo un error al almacenar en caché el TTL mínimo de 1 segundo en los errores de origen de S3. CloudFront lo hace para proteger su origen de los ataques DDoS. Esto no se aplica a otros tipos de orígenes.