Comportamiento de solicitudes y respuestas para orígenes personalizados - Amazon CloudFront
Cómo CloudFront procesa y reenvía las solicitudes a tu origen personalizado¿Cómo CloudFront procesa las respuestas de tu origen personalizado?

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Comportamiento de solicitudes y respuestas para orígenes personalizados

Cómo CloudFront procesa y reenvía las solicitudes a tu origen personalizado

En este tema se incluye información sobre cómo CloudFront procesa las solicitudes de los espectadores y cómo las reenvía a su origen personalizado.

Autenticación

En el caso de PUT las solicitudes DELETE GET HEAD PATCHPOST,,,, y, si CloudFrontconfiguras reenviar el Authorization encabezado a tu origen, puedes configurar tu servidor de origen para que solicite la autenticación del cliente.

En el caso de OPTIONS las solicitudes, puedes configurar tu servidor de origen para que solicite la autenticación del cliente solo si utilizas los siguientes CloudFront ajustes:

Puede configurarlo CloudFront para reenviar las solicitudes a su origen mediante HTTP o HTTPS; para obtener más información, consulteUso de HTTPS con CloudFront.

Duración de almacenamiento en caché y TTL mínimo

Para controlar cuánto tiempo permanecen tus objetos en la CloudFront caché antes de CloudFront reenviar otra solicitud a tu origen, puedes:

  • Configure su origen para añadir un Cache-Control o un encabezado Expires para cada objeto.

  • Especifique un valor para el TTL mínimo en los comportamientos de la CloudFront caché.

  • 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).

Direcciones IP de clientes

Si un espectador envía una solicitud CloudFront y no incluye un encabezado de X-Forwarded-For solicitud, CloudFront obtiene la dirección IP del espectador de la conexión TCP, agrega un X-Forwarded-For encabezado que incluye 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 espectador envía una solicitud CloudFront e incluye un encabezado de X-Forwarded-For solicitud, CloudFront obtiene la dirección IP del espectador de la conexión TCP, la agrega al final del X-Forwarded-For encabezado y reenvía la solicitud al origen. Por ejemplo, si la solicitud del espectador 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 los balanceadores de carga (incluido Elastic Load Balancing), los firewalls de aplicaciones web, los proxies inversos, los sistemas de prevención de intrusiones y API Gateway, añaden la dirección IP del servidor CloudFront perimetral que reenvió la solicitud al final del encabezado. X-Forwarded-For Por ejemplo, si se CloudFront incluye X-Forwarded-For: 192.0.2.2 en una solicitud que reenvía al ELB y si la dirección IP del servidor CloudFront perimetral es 192.0.2.199, la solicitud que recibe la instancia de 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 pueden modificar el X-Forwarded-For encabezado (). CloudFront Para obtener más información, consulte la sección 8.1 de RFC 7239. También puede modificar el encabezado mediante funciones de cálculo CloudFront perimetral.

Autenticación SSL en el cliente

CloudFront no admite la autenticación de clientes con certificados SSL del lado del cliente. Si un origen solicita un certificado del lado del cliente, CloudFront descarta la solicitud.

Compresión

Para obtener más información, consulte Ofrecer archivos comprimidos.

Solicitudes condicionales

Cuando CloudFront recibe una solicitud de un objeto caducado de una memoria caché perimetral, reenvía la solicitud al origen para obtener la versión más reciente del objeto o para que el origen confirme que la memoria caché CloudFront perimetral ya tiene la última versión. Normalmente, la última vez que el origen envió el objeto CloudFront, incluyó un ETag valor, un LastModified valor o ambos valores en la respuesta. En la nueva solicitud que se 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 usa esta información para determinar si el objeto se ha actualizado y, por lo tanto, si debe devolver todo el objeto CloudFront o solo un código de estado HTTP 304 (no modificado).

Cookies

Puede configurarlo CloudFront para que reenvíe las cookies a su origen. Para obtener más información, consulte Almacenamiento en caché de contenido en función de cookies.

Uso compartido de recursos entre orígenes (CORS)

Si quieres CloudFront respetar la configuración de uso compartido de recursos entre orígenes, configúrala CloudFront para que se reenvíe el Origin encabezado a tu origen. Para obtener más información, consulte Almacenamiento en caché de contenido en función de encabezados de solicitud.

Cifrado

Puedes exigir a los espectadores que utilicen HTTPS para enviar las solicitudes CloudFront y solicitar CloudFront que las reenvíen a tu origen personalizado mediante el protocolo que utilice el espectador. Para obtener más información, consulte la siguiente configuración de distribución:

CloudFront reenvía las solicitudes HTTPS al servidor de origen mediante los protocolos SSLv3, TLSv1.0, TLSv1.1 y TLSv1.2. 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 CloudFront consola, seleccione los protocolos mediante las casillas de verificación de los protocolos SSL de origen. Para obtener más información, consulte Creación de una distribución.

  • Si utilizas la CloudFront API, especifica los protocolos mediante el OriginSslProtocols elemento. Para obtener más información, consulta OriginSslProtocolsy consulta DistributionConfigla Amazon CloudFront API Reference.

Si el origen es un bucket de Amazon S3, CloudFront siempre se utiliza TLSv1.2.

importante

Otras versiones de SSL y TLS no son compatibles.

Para obtener más información sobre el uso de HTTPS con CloudFront, consulte. Uso de HTTPS con CloudFront Para ver una lista de los cifrados que CloudFront admiten la comunicación HTTPS entre los espectadores CloudFront y CloudFront su origen, consulteProtocolos y cifrados compatibles entre los espectadores y CloudFront.

Solicitudes GET que incluyen un cuerpo

Si la GET solicitud de un espectador incluye un cuerpo, CloudFront devuelve un código de estado HTTP 403 (prohibido) al espectador.

Métodos HTTP

Si se configura CloudFront para procesar todos los métodos HTTP que admite, CloudFront acepta las siguientes solicitudes de los espectadores y las reenvía a su origen personalizado:

  • DELETE

  • GET

  • HEAD

  • OPTIONS

  • PATCH

  • POST

  • PUT

CloudFront siempre guarda en caché las respuestas GET y solicitudes. HEAD También puede configurarlo CloudFront para almacenar en caché las respuestas a las OPTIONS solicitudes. 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 lo configura CloudFront para aceptar y reenviar a su origen todos los métodos HTTP CloudFront compatibles, configure su servidor de origen para que gestione todos los métodos. Por ejemplo, si te configuras CloudFront para aceptar y reenviar estos métodos porque quieres usarlosPOST, debes configurar tu servidor de origen para que gestione DELETE las solicitudes de forma adecuada, de modo que los espectadores no puedan eliminar los recursos que tú no deseas que eliminen. Para obtener más información, consulte la documentación de su servidor HTTP.

Encabezados y CloudFront comportamiento de las solicitudes HTTP (orígenes personalizados y 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:

  • CloudFront comportamiento si no está configurado CloudFront para reenviar el encabezado a su origen, lo que provoca CloudFront que los objetos se almacenen en caché en función de los valores del encabezado.

  • Si puedes configurar los objetos CloudFront para almacenar en caché los objetos en función de los valores de encabezado de ese encabezado.

    Puedes configurarlo CloudFront para almacenar en caché los objetos en función de los valores de User-Agent los encabezados Date y, pero no lo recomendamos. Estos encabezados tienen muchos valores posibles, y el almacenamiento en caché en función de sus valores provocaría que se CloudFront reenviaran muchas más solicitudes a tu 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.

Encabezado Comportamiento si no configuras la caché en función CloudFront de los valores de los encabezados Se admite el almacenamiento en caché admite en función de valores de encabezados

Encabezados definidos por otros

Configuración de caché antigua: CloudFront reenvía los encabezados a tu origen.

Sí

Accept

CloudFront elimina el encabezado.

Sí

Accept-Charset

CloudFront elimina el encabezado.

Sí

Accept-Encoding

Si el valor contiene gzip obr, CloudFront reenvía un Accept-Encoding encabezado normalizado a su origen.

Para obtener más información, consulte Compatibilidad con la compresión y Ofrecer archivos comprimidos.

Sí

Accept-Language

CloudFront elimina el encabezado.

Sí

Authorization

  • GETy HEAD solicitudes: CloudFront elimina el campo del Authorization encabezado antes de reenviar la solicitud a tu origen.

  • OPTIONSsolicitudes: CloudFront elimina el campo del Authorization encabezado antes de reenviar la solicitud a tu origen si configuras almacenar en caché las respuestas CloudFront a OPTIONS las solicitudes.

    CloudFront reenvía el campo de Authorization encabezado a tu origen si no lo configuras para almacenar en caché las respuestas CloudFront a las solicitudes de OPTIONS.

  • DELETE, PATCHPOST, y PUT solicitudes: CloudFront no elimina el campo de encabezado antes de reenviar la solicitud a tu origen.

Sí

Cache-Control

CloudFront reenvía el encabezado a tu origen.

No

CloudFront-Forwarded-Proto

CloudFront no añade el encabezado antes de reenviar la solicitud a tu origen.

Para obtener más información, consulte Configurar el almacenamiento en caché en función del protocolo de la solicitud.

Sí

CloudFront-Is-Desktop-Viewer

CloudFront no añade el encabezado antes de reenviar la solicitud a tu origen.

Para obtener más información, consulte Configuración del almacenamiento en caché en función del tipo de dispositivo.

Sí

CloudFront-Is-Mobile-Viewer

CloudFront no añade el encabezado antes de reenviar la solicitud a tu origen.

Para obtener más información, consulte Configuración del almacenamiento en caché en función del tipo de dispositivo.

Sí

CloudFront-Is-Tablet-Viewer

CloudFront no añade el encabezado antes de reenviar la solicitud a tu origen.

Para obtener más información, consulte Configuración del almacenamiento en caché en función del tipo de dispositivo.

Sí

CloudFront-Viewer-Country

CloudFront no añade el encabezado antes de reenviar la solicitud a tu origen.

Sí

Connection

CloudFront sustituye este encabezado por el de Connection: Keep-Alive antes de reenviar la solicitud a tu origen.

No

Content-Length

CloudFront reenvía el encabezado a tu origen.

No

Content-MD5

CloudFront reenvía el encabezado a tu origen.

Sí

Content-Type

CloudFront reenvía el encabezado a tu origen.

Sí

Cookie

Si CloudFront configuras el reenvío de cookies, reenviará el campo del Cookie encabezado a tu origen. Si no lo haces, CloudFront elimina el campo de Cookie encabezado. Para obtener más información, consulte Almacenamiento en caché de contenido en función de cookies.

No

Date

CloudFront reenvía el encabezado a tu origen.

Sí, pero no se recomienda

Expect

CloudFront elimina el encabezado.

Sí

From

CloudFront reenvía el encabezado a tu origen.

Sí

Host

CloudFront establece el valor del nombre de dominio del origen asociado al objeto solicitado.

No puede almacenar en caché en función del encabezado del host de Amazon S3 ni de MediaStore sus orígenes.

Sí (personalizado)

No (S3 y MediaStore)

If-Match

CloudFront reenvía el encabezado a tu origen.

Sí

If-Modified-Since

CloudFront reenvía el encabezado a tu origen.

Sí

If-None-Match

CloudFront reenvía el encabezado a tu origen.

Sí

If-Range

CloudFront reenvía el encabezado a tu origen.

Sí

If-Unmodified-Since

CloudFront reenvía el encabezado a tu origen.

Sí

Max-Forwards

CloudFront reenvía el encabezado a tu origen.

No

Origin

CloudFront reenvía el encabezado a tu origen.

Sí

Pragma

CloudFront reenvía el encabezado a tu 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 el encabezado a tu origen. Para obtener más información, consulte Cómo CloudFront procesa las solicitudes parciales de un objeto (range GET).

Sí de forma predeterminada

Referer

CloudFront elimina el encabezado.

Sí

Request-Range

CloudFront reenvía el encabezado a tu origen.

No

TE

CloudFront elimina el encabezado.

No

Trailer

CloudFront elimina el encabezado.

No

Transfer-Encoding

CloudFront reenvía el encabezado a tu origen.

No

Upgrade

CloudFront elimina el encabezado, a menos que hayas establecido una WebSocket conexión.

No (excepto en el caso de WebSocket las conexiones)

User-Agent

CloudFront reemplaza el valor de este campo de encabezado porAmazon CloudFront. Si CloudFront desea almacenar en caché el contenido en función del dispositivo que utilice el usuario, consulteConfiguración del almacenamiento en caché en función del tipo de dispositivo.

Sí, pero no se recomienda

Via

CloudFront reenvía el encabezado a su origen.

Sí

Warning

CloudFront reenvía el encabezado a tu origen.

Sí

X-Amz-Cf-Id

CloudFront añade el encabezado a la solicitud del espectador antes de reenviar la solicitud a tu origen. El valor de encabezado contiene una cadena cifrada que identifica la solicitud de forma única.

No

X-Edge-*

CloudFront elimina todos los X-Edge-* encabezados.

No

X-Forwarded-For

CloudFront reenvía el encabezado a su origen. Para obtener más información, consulte Direcciones IP de clientes.

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 construye 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 al espectador el código de estado HTTP 413 (Request Entity Too Large) y, a continuación, finaliza la conexión TCP con el espectador.

Asociación de OCSP

Cuando un espectador envía una solicitud HTTPS para un objeto, CloudFront o bien el espectador debe confirmar con la autoridad de certificación (CA) que el certificado SSL del dominio no se ha revocado. El grapado OCSP acelera la validación del certificado CloudFront al permitir validarlo y almacenar en caché la respuesta de la CA, de modo que el cliente no necesite validar el certificado directamente con la CA.

La mejora del rendimiento del grapado OCSP es más pronunciada cuando se CloudFront reciben numerosas solicitudes HTTPS de objetos del mismo dominio. Cada servidor en una ubicación de borde de CloudFront debe enviar una solicitud de validación independiente. Al CloudFront recibir muchas solicitudes HTTPS para el mismo dominio, todos los servidores de la ubicación perimetral reciben pronto una respuesta de la CA que pueden «grapar» en un paquete mediante el protocolo de enlace SSL; cuando el espectador está convencido de que el certificado es válido, CloudFront puede enviar el objeto solicitado. Si la distribución no recibe mucho tráfico en una ubicación de borde 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 espectador realiza el paso de validación por separado y el CloudFront servidor entrega el objeto. Ese CloudFront servidor también envía una solicitud de validación a la CA, de modo que la próxima vez que reciba una solicitud que incluya el mismo nombre de dominio, recibirá una respuesta de validación de la CA.

Conexiones persistentes

Cuando CloudFront recibe una respuesta de su origen, intenta mantener la conexión durante varios segundos en caso de que llegue otra solicitud durante ese período. 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) en la sección Valores que deben especificarse al crear o actualizar una distribución.

Protocolos

CloudFront reenvía las solicitudes HTTP o HTTPS al servidor de origen en función de lo siguiente:

  • El protocolo de la solicitud que el espectador envía CloudFront, ya sea HTTP o HTTPS.

  • El valor del campo Origin Protocol Policy de la CloudFront consola o, si utilizas la CloudFront API, el OriginProtocolPolicy elemento del tipo DistributionConfig complejo. En la CloudFront consola, las opciones son Solo HTTP, Solo HTTPS y Match Viewer.

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 espectador.

Si especificas Match Viewer, CloudFront reenvía las solicitudes al servidor de origen mediante el protocolo de la solicitud del visor. Ten en cuenta que el objeto se guarda en CloudFront caché solo una vez, incluso si los espectadores realizan solicitudes mediante 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 un certificado autofirmado, interrumpe la conexión CloudFront TCP.

Para obtener información sobre cómo actualizar una distribución mediante la CloudFront consola, consulte. Actualización de una distribución Para obtener información sobre cómo actualizar una distribución mediante la CloudFront API, consulta la referencia UpdateDistributionde la CloudFront API de Amazon.

Cadenas de consulta

Puede configurar si CloudFront reenvía los parámetros de la cadena 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.

Tiempo de espera e intentos de conexión de origen

El tiempo de espera de la conexión de origen es el número de segundos que se CloudFront espera al intentar establecer una conexión con el origen.

Los intentos de conexión de origen son el número de veces que se CloudFront intenta conectar al origen.

En conjunto, estas configuraciones determinan cuánto tiempo se CloudFront intenta conectarse al origen antes de pasar por error al origen secundario (en el caso de un grupo de origen) o devolver una respuesta de error al espectador. 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 los tiempos de espera de origen y los intentos.

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 tiempo, en segundos, que se CloudFront espera una respuesta después de reenviar una solicitud al origen.

  • El tiempo, en segundos, que se CloudFront espera después de recibir un paquete de una respuesta del origen y antes de recibir el siguiente paquete.

CloudFront el comportamiento depende del método HTTP de la solicitud del espectador:

  • GETy HEAD solicitudes: si el origen no responde o deja de responder dentro del tiempo de espera de la respuesta, CloudFront se interrumpe la conexión. Si el número especificado de intentos de conexión de origen es superior a 1, vuelve a CloudFront intentarlo para obtener una respuesta completa. CloudFront lo intenta hasta 3 veces, según lo determine el valor de la configuración de intentos de conexión de origen. Si el origen no responde durante el último intento, CloudFront no lo vuelva a intentar hasta que reciba otra solicitud de contenido del mismo origen.

  • DELETE,OPTIONS, PATCHPUT, y POST solicitudes: si el origen no responde en 30 segundos, CloudFront interrumpe la conexión y no vuelve a intentar contactar 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 (solo orígenes personalizados).

Solicitudes simultáneas del mismo objeto (contracción de solicitudes)

Cuando una ubicación de CloudFront borde recibe una solicitud de un objeto y el objeto no está en la caché o el objeto en caché ha caducado, envía CloudFront inmediatamente la solicitud al origen. Sin embargo, si hay solicitudes simultáneas para el mismo objeto, es decir, si llegan más solicitudes para el mismo objeto (con la misma clave de caché) a la ubicación de borde antes de CloudFront recibir la respuesta a la primera solicitud, se CloudFront detiene 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 CloudFront los registros, la primera solicitud se identifica como a Miss en el x-edge-result-type campo y las solicitudes contraídas se identifican como aHit. Para obtener más información sobre CloudFront los registros, consulteCloudFront y registro de funciones periféricas.

CloudFront solo contrae las solicitudes que comparten una clave de caché. Si las solicitudes adicionales no comparten la misma clave de caché porque, por ejemplo, CloudFront configuraste la caché en función de los encabezados de las solicitudes, las cookies o las cadenas de consulta, CloudFront reenvía todas las solicitudes con una clave de caché única a tu origen.

Si quieres evitar que todas las solicitudes se colapsen, puedes usar la política de caché administradaCachingDisabled, que también evita el almacenamiento en caché. Para obtener más información, consulte Uso de las políticas de caché administradas.

Si desea 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 tu lugar de origen e introducirán una latencia adicional para las solicitudes simultáneas que se pausen mientras esperan CloudFront la respuesta a la primera solicitud.

Encabezado User-Agent

Si CloudFront quieres almacenar en caché diferentes versiones de tus objetos en función del dispositivo que utilice el usuario para ver tu contenido, te recomendamos que lo configures CloudFront para reenviar uno o varios de los siguientes encabezados a tu origen personalizado:

  • CloudFront-Is-Desktop-Viewer

  • CloudFront-Is-Mobile-Viewer

  • CloudFront-Is-SmartTV-Viewer

  • CloudFront-Is-Tablet-Viewer

En función del valor del User-Agent encabezado, CloudFront establece el valor de estos encabezados false antes true o antes de reenviar la solicitud a tu origen. Si un dispositivo entra en más de una categoría, más de un valor podría ser true. Por ejemplo, en algunas tabletas, CloudFront puede establecer ambos valores comoCloudFront-Is-Mobile-Viewer. CloudFront-Is-Tablet-Viewer true Para obtener más información sobre cómo CloudFront configurar la memoria caché en función de los encabezados de las solicitudes, consulteAlmacenamiento en caché de contenido en función de encabezados de solicitud.

Puede configurarlo CloudFront para almacenar en caché los objetos en función de los valores del User-Agent encabezado, pero no lo recomendamos. El User-Agent encabezado tiene muchos valores posibles, y el almacenamiento en caché en función de esos valores provocaría que se CloudFront reenviaran muchas más solicitudes a tu origen.

Si no configuras los objetos CloudFront para almacenar en caché los objetos en función de los valores del User-Agent encabezado, CloudFront añade un User-Agent encabezado con el siguiente valor antes de reenviar una solicitud a tu origen:

User-Agent = Amazon CloudFront

CloudFront añade este encabezado independientemente de si la solicitud del visor incluye un User-Agent encabezado. Si la solicitud del espectador incluye un User-Agent encabezado, lo CloudFront elimina.

¿Cómo CloudFront procesa las respuestas de tu origen personalizado?

Este tema contiene información sobre cómo CloudFront procesa las respuestas de su origen personalizado.

100 Continue respuestas

Tu origen no puede enviar más de una respuesta a CloudFront 100 personas. Tras la primera respuesta de 100 pasos, CloudFront espera una respuesta HTTP 200 OK. Si tu origen envía otra respuesta de 100 pasos después de la primera, CloudFront devolverá un error.

Almacenamiento en caché

Solicitudes canceladas

Si un objeto no está en la caché perimetral y si un espectador termina una sesión (por ejemplo, cierra un navegador) después de obtener el CloudFront objeto de su origen, pero antes de poder entregar el objeto solicitado, CloudFront no lo guarda en caché en la ubicación perimetral.

Negociación de contenido

Si tu origen vuelve a aparecer Vary:* en la respuesta y si el valor del TTL mínimo para el comportamiento de la caché correspondiente es 0, guarda en CloudFront caché el objeto pero reenvía todas las solicitudes subsiguientes del objeto al origen para confirmar que la caché contiene la última versión del objeto. CloudFront no incluye ningún encabezado condicional, como o. If-None-Match If-Modified-Since Como resultado, tu origen devuelve el objeto CloudFront en respuesta a todas las solicitudes.

Si su origen aparece Vary:* en la respuesta y si el valor del TTL mínimo para el comportamiento de la caché correspondiente es cualquier otro valor, CloudFront procesa el Vary encabezado tal y como se describe enCabeceras de respuesta HTTP que CloudFront eliminan o sustituyen.

Cookies

Si habilitas las cookies para un comportamiento de caché y si el origen devuelve cookies con un objeto, guarda en CloudFront 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.

Conexiones TCP interrumpidas

Si la conexión TCP entre CloudFront y tu origen se interrumpe mientras tu origen devuelve un objeto a CloudFront, el CloudFront comportamiento depende de si tu origen ha incluido un Content-Length encabezado en la respuesta:

  • Cabecera Content-Length: CloudFront devuelve el objeto al espectador a medida que recibe el objeto de tu origen. Sin embargo, si el valor del encabezado Content-Length no coincide con el tamaño del objeto, CloudFront no lo almacena en caché.

  • Codificación por transferencia: fragmentada: CloudFront devuelve el objeto al espectador a medida que recibe el objeto de tu origen. Sin embargo, si la respuesta fragmentada no está completa, CloudFront no almacena el objeto en caché.

  • Sin encabezado Content-Length: CloudFront devuelve el objeto al espectador y lo almacena en caché, pero es posible que el objeto no esté completo. Sin un Content-Length encabezado, CloudFront no se puede determinar si la conexión TCP se interrumpió accidentalmente o a propósito.

Se recomienda configurar el servidor HTTP para añadir un Content-Length encabezado a fin de CloudFront evitar que se almacenen en caché objetos parciales.

Cabeceras de respuesta HTTP que CloudFront eliminan o sustituyen

CloudFront elimina o actualiza los siguientes campos de encabezado antes de reenviar la respuesta desde su origen al espectador:

  • Set-Cookie— Si CloudFront configuras el reenvío de cookies, reenviará el campo del Set-Cookie encabezado a los clientes. Para obtener más información, consulte Almacenamiento en caché de contenido en función de cookies.

  • Trailer

  • Transfer-Encoding— Si tu origen devuelve este campo de encabezado, CloudFront establece el valor en chunked antes de devolver la respuesta al espectador.

  • Upgrade

  • Vary: tenga en cuenta lo siguiente:

    • Si configuras CloudFront para reenviar alguno de los encabezados específicos del dispositivo a tu origen (CloudFront-Is-Desktop-Viewer,, CloudFront-Is-Mobile-ViewerCloudFront-Is-SmartTV-Viewer,CloudFront-Is-Tablet-Viewer) y configuras tu origen para que vuelva Vary:User-Agent a CloudFront, volverá al CloudFront visorVary:User-Agent. Para obtener más información, consulte Configuración del almacenamiento en caché en función del tipo de dispositivo.

    • Si configuras tu origen para incluir uno Accept-Encoding o varios Cookie en el Vary encabezado, CloudFront incluye los valores en la respuesta al espectador.

    • Si lo configuras CloudFront para reenviar los encabezados a tu origen y si lo configuras para que devuelva los nombres de los encabezados CloudFront en el Vary encabezado (por ejemplo,Vary:Accept-Charset,Accept-Language), CloudFront devolverá el Vary encabezado con esos valores al espectador.

    • Para obtener información sobre cómo CloudFront procesa un valor de * en el Vary encabezado, consulteNegociación de contenido.

    • Si configura su origen para incluir cualquier otro valor en el Vary encabezado, CloudFront elimina los valores antes de devolver la respuesta al espectador.

  • Via— CloudFront establece el siguiente valor en la respuesta al espectador:

    Via: versión-http cadena-alfanumérica.cloudfront.net (CloudFront)

    Por ejemplo, si el cliente realiza una solicitud a través de HTTP/1.1, el valor es algo parecido 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 del cuerpo de la respuesta que se CloudFront guarda en la memoria caché es de 50 GB. Eso incluye respuestas transferidas en fragmentos que no especifican el valor de encabezado Content-Length.

CloudFront Para almacenar en caché un objeto con un tamaño superior a este, utilice solicitudes de rango para solicitar los objetos en partes de 50 GB o menos cada una. CloudFrontalmacena en caché estas partes porque cada una de ellas tiene 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.

Origen no disponible

Si el servidor de origen no está disponible y CloudFront recibe una solicitud de un objeto que está en la memoria caché perimetral pero que ha caducado (por ejemplo, porque ha pasado el período de tiempo especificado en la Cache-Control max-age directiva), CloudFront muestra la versión caducada del objeto o muestra 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 ha configurado páginas de error personalizadas.

En algunos casos, un objeto que se solicita con poca frecuencia se desaloja y deja de estar disponible en la memoria caché perimetral. CloudFront no puede servir un objeto que ha 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. Tras configurar la redirección, la primera vez que un espectador envía una solicitud para el objeto, CloudFront Front envía la solicitud al origen y este responde con una redirección (por ejemplo,302 Moved Temporarily). CloudFront guarda en caché el redireccionamiento y lo devuelve al espectador. CloudFront no sigue la redirección.

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 espectador sigue la redirección a la nueva URL, la omite 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 CloudFront URL del objeto. Cuando el espectador envía la solicitud que contiene la nueva CloudFront URL, CloudFront obtiene el objeto de la nueva ubicación de origen, lo guarda en caché en la ubicación perimetral y devuelve el objeto al espectador. 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.

Encabezado Transfer-Encoding

CloudFront solo admite el chunked valor del Transfer-Encoding encabezado. Si su origen regresaTransfer-Encoding: chunked, CloudFront devuelve el objeto al cliente a medida que el objeto se recibe en la ubicación perimetral y lo almacena en caché en formato fragmentado para las solicitudes posteriores.

Si el espectador hace una Range GET solicitud y el origen regresaTransfer-Encoding: chunked, CloudFront devuelve todo el objeto al espectador en lugar del rango 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.