Comportement des demandes et des réponses pour les origines personnalisées - Amazon CloudFront

Si nous fournissons une traduction de la version anglaise du guide, la version anglaise du guide aura préséance en cas de contradiction. La traduction sera une traduction automatique.

Comportement des demandes et des réponses pour les origines personnalisées

Traitement et transmission des demandes à votre serveur d'origine personnalisée par CloudFront

Cette rubrique contient des informations sur la façon dont CloudFront traite les demandes de l'utilisateur et les transmet à votre origine personnalisée.

Authentication

Pour les requêtes DELETE, GET, HEAD, PATCH, POST et PUT, si vous configurez CloudFront pour qu'il transmette l'en-tête Authorization à votre origine, vous pouvez configurer votre serveur d'origine pour qu'il demande une authentification du client.

Pour les requêtes OPTIONS, vous pouvez configurer votre serveur d'origine pour qu'il demande une authentification du client uniquement si vous utilisez les paramètres CloudFront suivants :

  • Configurer CloudFront de manière à transférer l'en-tête Authorization à votre origine.

  • Configurer CloudFront de manière à ne pas mettre en cache les réponses aux demandes OPTIONS.

Vous pouvez configurer CloudFront de sorte qu'il transmette des requêtes à votre origine à l'aide de HTTP ou HTTPS ; Pour plus d'informations, consultez Utilisation du protocole HTTPS avec CloudFront.

Durée de conservation dans le cache et durée de vie minimale

Pour les distributions web, afin de contrôler le temps pendant lequel les objets restent dans le cache CloudFront avant que CloudFront ne transmette une autre requête à votre origine, vous pouvez :

  • Configurer votre origine pour ajouter un Cache-Control ou un champ d'en-tête Expires à chaque objet.

  • Spécifier une valeur de durée de vie minimale dans les comportements de cache CloudFront.

  • Utiliser la valeur par défaut de 24 heures.

Pour plus d'informations, consultez Gestion de la durée de conservation de contenu dans le cache périphérique (expiration),

Adresses IP client

Si un utilisateur envoie une requête à CloudFront et n'inclut pas un en-tête de requête X-Forwarded-For, CloudFront extrait l'adresse IP de l'utilisateur de la connexion TCP, ajoute un en-tête X-Forwarded-For qui inclut l'adresse IP et transmet la requête à l'origine. Par exemple, si CloudFront extrait l'adresse IP 192.0.2.2 de la connexion TCP, il transmet l'en-tête suivant à l'origine :

X-Forwarded-For: 192.0.2.2

Si un utilisateur envoie une requête à CloudFront et inclut un en-tête de requête X-Forwarded-For, CloudFront extrait l'adresse IP de l'utilisateur de la connexion TCP, l'ajoute à la fin de l'en-tête X-Forwarded-For et transmet la requête à l'origine. Par exemple, si la requête de l'utilisateur inclut X-Forwarded-For: 192.0.2.4,192.0.2.3 et que CloudFront extrait l'adresse IP 192.0.2.2 de la connexion TCP, il transmet l'en-tête suivant à l'origine :

X-Forwarded-For: 192.0.2.4,192.0.2.3,192.0.2.2

Certaines applications, comme des équilibreurs de charge (notamment Elastic Load Balancing), des pare-feux d'application Web, des proxys inverses, des systèmes de prévention d'intrusion et des passerelles API, ajoutent l'adresse IP au serveur périphérique CloudFront qui a transmis la requête à la fin de l'en-tête X-Forwarded-For. Par exemple, si CloudFront inclut X-Forwarded-For: 192.0.2.2 dans une requête qu'il transmet à ELB et si l'adresse IP du serveur périphérique CloudFront est 192.0.2.199, la requête reçue par votre instance EC2 contient l'en-tête suivant :

X-Forwarded-For: 192.0.2.2,192.0.2.199

Note

L'en-tête X-Forwarded-For contient les adresses IPv4 (par exemple, 192.0.2.44) et les adresses IPv6 (par exemple, 2001:0db8:85a3:0000:0000:8a2e:0370:7334).

Authentification SSL côté client

CloudFront ne prend pas en charge l'authentification avec des certificats SSL côté client. Si une origine demande un certificat côté client, CloudFront supprime la demande.

Compression

CloudFront transmet les demandes qui ont Accept-Encoding valeurs de champ "identity" et "gzip". Pour plus d’informations, voir Service de fichiers compressés.

Demandes conditionnelles

Lorsque CloudFront reçoit une requête d'objet ayant expiré d'un cache périphérique, il transmet la requête à l'origine pour obtenir la dernière version de l'objet ou avoir la confirmation de l'origine que le cache périphérique CloudFront dispose déjà de la dernière version. Généralement, lorsque l'origine a envoyé l'objet à CloudFront la dernière fois, il a inclus une valeur ETag, une valeur LastModified, ou les deux, dans la réponse. Dans la nouvelle requête que CloudFront transmet à l'origine, CloudFront ajoute l'un des éléments suivants, ou les deux :

  • Un en-tête If-Match ou If-None-Match qui contient la valeur ETag pour la version expirée de l'objet.

  • Un en-tête If-Modified-Since qui contient la valeur LastModified pour la version expirée de l'objet.

L'origine utilise ces informations pour déterminer si l'objet a été mis à jour, et donc, s'il doit renvoyer l'objet entier à CloudFront ou uniquement un code de statut HTTP 304 (non modifié).

Cookies

Vous pouvez configurer CloudFront de manière à transmettre les cookies à votre origine. Pour plus d'informations, consultez Mise en cache de contenu basée sur des cookies,

Partage des ressources cross-origine (CORS)

Si vous souhaitez que CloudFront respecte les paramètres de partage des ressources cross-origine, configurez CloudFront de manière à ce qu'il transmette l'en-tête Origin à votre origine. Pour plus d'informations, consultez Mise en cache de contenu basée sur des en-têtes de requêtes,

Encryption

Vous pouvez exiger que les utilisateurs envoient les requêtes à CloudFront via HTTPS et que CloudFront transmette les requêtes à votre origine personnalisée à l'aide du protocole utilisé par l'utilisateur. Pour plus d'informations, consultez les paramètres de distribution suivants :

CloudFront transmet les requêtes HTTPS au serveur d'origine à l'aide des protocoles SSLv3, TLSv1.0, TLSv1.1 et TLSv1.2. Pour les origines personnalisées, vous pouvez choisir les protocoles SSL que CloudFront doit utiliser lors de la communication avec votre origine :

  • Si vous utilisez la console CloudFront, choisissez les protocoles à l'aide des cases à cocher Origin SSL Protocols (Protocoles SSL d'origine). Pour plus d'informations, consultez Création d'une distribution,

  • Si vous utilisez l'API CloudFront, spécifiez les protocoles à l'aide de l'élément OriginSslProtocols. Pour plus d'informations, consultez OriginSslProtocols et DistributionConfig dans le document Amazon CloudFront API Reference.

Si l'origine est un compartiment Amazon S3, CloudFrontutilise toujours TLSv1.2.

Important

Les autres versions de SSL et TLS ne sont pas prises en charge.

Pour en savoir plus sur l'utilisation du protocole HTTPS avec CloudFront, consultez Utilisation du protocole HTTPS avec CloudFront. Pour consulter les listes de chiffrements pris en charge par CloudFront pour les communications HTTPS entre les utilisateurs et CloudFront, et entre CloudFront et votre origine, consultez Protocoles SSL/TLS pris en charge et chiffrement pour la communication entre les visionneuses et CloudFront.

Demandes GET qui incluent un corps de texte

Si une requête utilisateur GET inclut un corps de texte, CloudFront renvoie un code de statut HTTP 403 (Interdit) à l'utilisateur.

Méthodes HTTP

Si vous configurez CloudFront pour qu'il traite toutes les méthodes HTTP qu'il prend en charge, CloudFront accepte les requêtes utilisateur suivantes et les transmet à votre origine personnalisée :

  • DELETE

  • GET

  • HEAD

  • OPTIONS

  • PATCH

  • POST

  • PUT

CloudFront met toujours en cache les réponses aux requêtes GET et HEAD. Vous pouvez également configurer CloudFront pour qu'il mette en cache les réponses apportées aux requêtes OPTIONS. CloudFront ne met pas en cache les réponses aux requêtes qui utilisent d'autres méthodes.

Pour plus d'informations sur la façon de configurer si votre origine personnalisée traite ces méthodes, consultez la documentation de votre origine.

Important

Si vous configurez CloudFront pour qu'il accepte et transmette à votre origine toutes les méthodes HTTP prises en charge par CloudFront, configurez votre serveur d'origine pour qu'il traite toutes les méthodes. Par exemple, si vous configurez CloudFront pour qu'il accepte et transmette ces méthodes parce que vous voulez utiliser POST, vous devez configurer votre serveur d'origine de manière à ce qu'il gère correctement les requêtes DELETE, de sorte que les utilisateurs ne puissent pas supprimer les ressources que vous ne les autorisez pas à supprimer. Pour plus d'informations, consultez la documentation de votre serveur HTTP.

En-têtes de requête HTTP et comportement de CloudFront (origines S3 et personnalisée)

Le tableau suivant répertorie les en-têtes de requête HTTP que vous pouvez transmettre aux origines Amazon S3 et personnalisée (avec les exceptions qui sont notées). Pour chaque en-tête, le tableau comprend des informations sur les points suivants :

  • Le comportement de CloudFront si vous ne configurez pas CloudFront pour qu'il transmette l'en-tête à votre origine, ce qui entraîne la mise en cache par CloudFront de vos objets en fonction des valeurs d'en-tête.

  • Si vous pouvez configurer CloudFront pour mettre en cache des objets selon des valeurs d'en-tête pour cet en-tête.

    Vous pouvez configurer CloudFront pour mettre en cache des objets selon les valeurs des en-têtes Date et User-Agent, mais ceci n'est pas recommandé. Ces en-têtes possèdent de nombreuses valeurs possibles, et la mise en cache selon leurs valeurs entraînerait la transmission par CloudFront de beaucoup plus de demandes à votre origine.

Pour plus d'informations sur la mise en cache selon des valeurs d'en-tête, consultez Mise en cache de contenu basée sur des en-têtes de requêtes.

En-tête Comportement si vous ne configurez pas CloudFront pour effectuer la mise en cache en fonction de valeurs d'en-tête. La mise en cache en fonction de valeurs d'en-tête est prise en charge

En-têtes définis par un tiers

CloudFront transmet les en-têtes à votre origine.

 : oui

Accept

CloudFront supprime l'en-tête.

 : oui

Accept-Charset

CloudFront supprime l'en-tête.

 : oui

Accept-Encoding

Si la valeur contient gzip, CloudFront transmet Accept-Encoding: gzip à votre origine.

Si la valeur ne contient pas gzip, CloudFront supprime le champ d'en-tête Accept-Encoding avant de transmettre la requête à votre origine.

 : oui

Accept-Language

CloudFront supprime l'en-tête.

 : oui

Authorization

  • Requêtes GET etHEAD– CloudFront supprime le champ d'en-tête Authorization avant de transmettre la requête à votre origine.

  • Requêtes OPTIONS– CloudFront supprime le champ d'en-tête Authorization avant de transmettre la requête à votre origine si vous configurez CloudFront pour qu'il mette en cache les réponses aux requêtes OPTIONS.

    CloudFront transmet le champ d'en-tête Authorization à votre origine si vous ne configurez pas CloudFront pour qu'il mette en cache les réponses aux requêtes OPTIONS.

  • Requêtes DELETE, PATCH, POST et PUT– CloudFront ne supprime pas le champ d'en-tête avant de transmettre la requête à votre origine.

 : oui

Cache-Control

CloudFront transmet l'en-tête à votre origine.

Non.

CloudFront-Forwarded-Proto

CloudFront n'ajoute pas l'en-tête avant de transmettre la demande à votre origine.

Pour plus d'informations, consultez Configuration de la mise en cache en fonction du protocole de la demande,

 : oui

CloudFront-Is-Desktop-Viewer

CloudFront n'ajoute pas l'en-tête avant de transmettre la demande à votre origine.

Pour plus d'informations, consultez Configuration de la mise en cache en fonction du type d'appareil,

 : oui

CloudFront-Is-Mobile-Viewer

CloudFront n'ajoute pas l'en-tête avant de transmettre la demande à votre origine.

Pour plus d'informations, consultez Configuration de la mise en cache en fonction du type d'appareil,

 : oui

CloudFront-Is-Tablet-Viewer

CloudFront n'ajoute pas l'en-tête avant de transmettre la demande à votre origine.

Pour plus d'informations, consultez Configuration de la mise en cache en fonction du type d'appareil,

 : oui

CloudFront-Viewer-Country

CloudFront n'ajoute pas l'en-tête avant de transmettre la demande à votre origine.

 : oui

Connection

CloudFront remplace cet en-tête par Connection: Keep-Alive avant de transmettre la requête à votre origine.

Non.

Content-Length

CloudFront transmet l'en-tête à votre origine.

Non.

Content-MD5

CloudFront transmet l'en-tête à votre origine.

 : oui

Content-Type

CloudFront transmet l'en-tête à votre origine.

 : oui

Cookie

Si vous configurez CloudFront de sorte qu'il transmette les cookies, il transmettra le champ d'en-tête Cookie à votre origine. Sinon, CloudFront supprime le champ d'en-tête Cookie. Pour plus d'informations, consultez Mise en cache de contenu basée sur des cookies,

Non.

Date

CloudFront transmet l'en-tête à votre origine.

Oui, mais non recommandé

Expect

CloudFront supprime l'en-tête.

 : oui

From

CloudFront transmet l'en-tête à votre origine.

 : oui

Host

CloudFront définit la valeur sur le nom de domaine de l'origine qui est associée à l'objet demandé.

Vous ne pouvez pas effectuer la mise en cache en fonction de l'en-tête d'hôte pour les origines Amazon S3 et MediaStore.

Oui (personnalisée)

Non (S3 et MediaStore)

If-Match

CloudFront transmet l'en-tête à votre origine.

 : oui

If-Modified-Since

CloudFront transmet l'en-tête à votre origine.

 : oui

If-None-Match

CloudFront transmet l'en-tête à votre origine.

 : oui

If-Range

CloudFront transmet l'en-tête à votre origine.

 : oui

If-Unmodified-Since

CloudFront transmet l'en-tête à votre origine.

 : oui

Max-Forwards

CloudFront transmet l'en-tête à votre origine.

Non.

Origin

CloudFront transmet l'en-tête à votre origine.

 : oui

Pragma

CloudFront transmet l'en-tête à votre origine.

Non.

Proxy-Authenticate

CloudFront supprime l'en-tête.

Non.

Proxy-Authorization

CloudFront supprime l'en-tête.

Non.

Proxy-Connection

CloudFront supprime l'en-tête.

Non.

Range

CloudFront transmet l'en-tête à votre origine. Pour plus d'informations, consultez Traitement par CloudFront des demandes partielles pour un objet (Range GET),

Oui, par défaut

Referer

CloudFront supprime l'en-tête.

 : oui

Request-Range

CloudFront transmet l'en-tête à votre origine.

Non.

TE

CloudFront supprime l'en-tête.

Non.

Trailer

CloudFront supprime l'en-tête.

Non.

Transfer-Encoding

CloudFront transmet l'en-tête à votre origine.

Non.

Upgrade

CloudFront supprime l'en-tête, sauf si vous avez établi une connexion WebSocket.

Non (sauf pour les connexions WebSocket)

User-Agent

la face avant remplace la valeur de ce champ d’en-tête par Amazon CloudFront. Si vous voulez CloudFront pour mettre en cache votre contenu en fonction du périphérique que l’utilisateur utilise, voir Configuration de la mise en cache en fonction du type d'appareil.

Oui, mais non recommandé

Via

CloudFront transmet l'en-tête à votre origine.

 : oui

Warning

CloudFront transmet l'en-tête à votre origine.

 : oui

X-Amz-Cf-Id

CloudFront ajoute l'en-tête à la demande de l'utilisateur avant de transmettre la demande à votre origine. La valeur d'en-tête contient une chaîne chiffrée qui identifie de façon unique la demande.

Non.

X-Edge-*

CloudFront supprime tous les en-têtes X-Edge-*.

Non.

X-Forwarded-For

CloudFront transmet l'en-tête à votre origine. Pour plus d'informations, consultez Adresses IP client,

 : oui

X-Forwarded-Proto

CloudFront supprime l'en-tête.

Non.

X-Real-IP

CloudFront supprime l'en-tête.

Non.

Version de HTTP

CloudFront transmet les demandes à votre origine personnalisée à l'aide de HTTP/1.1.

Longueur maximale d'une demande et longueur maximale d'une URL

La longueur maximale d'une demande, avec le chemin, la chaîne de requête (le cas échéant) et les en-têtes inclus, est de 20480 octets.

CloudFront crée une URL à partir de la demande. La longueur maximale de cette URL est de 8 192 caractères.

Si une demande ou une URL dépasse ces limites, CloudFront renvoie le code de statut HTTP 413 (Entité de demande trop volumineuse) à l'utilisateur, puis met fin à la connexion TCP avec ce dernier.

OCSP Stapling

Lorsqu'une visionneuse soumet une requête HTTPS pour un objet, CloudFront ou la visionneuse doit vérifier auprès de l'autorité de certification (CA) que le certificat SSL pour le domaine n'a pas été révoqué. OCSP Stapling accélère la validation du certificat en permettant à CloudFront de valider le certificat et de mettre en cache la réponse de l'autorité de certification. Le client n'a donc pas besoin de valider le certificat directement auprès de l'autorité de certification.

L'amélioration des performances d'OCSP Stapling est plus prononcée lorsque CloudFront reçoit de nombreuses requêtes HTTPS pour des objets dans le même domaine. Chaque serveur d'un emplacement périphérique CloudFront doit soumettre une demande de validation distincte. Lorsque CloudFront reçoit de nombreuses requêtes HTTPS pour le même domaine, chaque serveur dans l'emplacement périphérique reçoit rapidement une réponse de l'autorité de certification qu'il peut « agrafer » (staple) dans un paquet de l'établissement de la liaison SSL ; lorsque l'utilisateur a vérifié que le certificat est valide, CloudFront peut servir l'objet demandé. Si votre distribution ne reçoit pas beaucoup de trafic dans un emplacement périphérique CloudFront, il est plus probable que les nouvelles demandes soient acheminées vers un serveur qui n'a pas encore validé le certificat auprès de l'autorité de certification. Dans ce cas, l'utilisateur exécute séparément l'étape de validation et le serveur CloudFront sert l'objet. Ce serveur CloudFront soumet également une demande de validation à l'autorité de certification. De ce fait, la fois suivante qu'il reçoit une demande incluant le même nom de domaine, il dispose d'une réponse de validation de l'autorité de certification.

Connexions persistantes

Lorsque CloudFront obtient une réponse de votre origine, il essaye de maintenir la connexion pendant plusieurs secondes au cas où une autre demande arrive au cours de cette période. Maintenir une connexion persistante permet de gagner le temps requis pour ré-établir la connexion TCP et établir une autre liaison TLS pour les demandes ultérieures.

Pour plus d'informations, y compris sur la manière de configurer la durée des connexions persistantes, consultez Délai d'attente des connexions actives dans la section Valeurs que vous spécifiez lorsque vous créez ou mettez à jour une distribution.

Protocols

CloudFront transmet les requêtes HTTP ou HTTPS au serveur d'origine selon les éléments suivants :

  • Le protocole de la demande que l'utilisateur envoie à CloudFront, HTTP ou HTTPS.

  • La valeur du champ Origin Protocol Policy (Stratégie de protocole d'origine) sur la console CloudFront ou, si vous utilisez l'API CloudFront, l'élément OriginProtocolPolicy du type complexe DistributionConfig. Dans la console CloudFront, les options sont HTTP Only (HTTP uniquement), HTTPS Only (HTTPS uniquement) et Match Viewer (Identique à l'utilisateur).

Si vous spécifiez HTTP Only (HTTP uniquement) ou HTTPS Only (HTTPS uniquement), CloudFront transmet les requêtes au serveur d'origine selon le protocole spécifié, quel que soit le protocole de la requête utilisateur.

Si vous spécifiez Match Viewer (Identique à l'utilisateur), CloudFront transmet les requêtes au serveur d'origine selon le protocole de la requête utilisateur. Notez que CloudFront ne met l'objet en cache qu'une seule fois, même si les utilisateurs émettent des demandes à l'aide des protocoles HTTP et HTTPS.

Important

Si CloudFront transmet une requête à l'origine via le protocole HTTPS et si le serveur d'origine renvoie un certificat non valide ou un certificat auto-signé, CloudFront annule la connexion TCP.

Pour en savoir plus sur la mise à jour d'une distribution à l'aide de la console CloudFront, consultez Mise à jour d'une distribution. Pour plus d'informations sur la mise à jour d'une distribution à l'aide de l'API CloudFront, consultez UpdateDistribution dans le document Amazon CloudFront API Reference.

Chaînes de requête

Vous pouvez configurer CloudFront pour transmettre les paramètres de chaîne de requête à votre origine. Pour plus d'informations, consultez Mise en cache de contenu basée sur les paramètres de chaîne de requête,

Délai d'attente et tentatives de connexion à l’origine

Délai d'expiration de la connexion à l'origine désigne le nombre de secondes pendant lesquelles CloudFront attend lorsque vous essayez d'établir une connexion à l'origine.

Tentatives de connexion de l'origine désigne le nombre de tentatives de connexion d'CloudFront à l'origine.

Ensemble, ces paramètres déterminent la durée des tentatives de connexion d'CloudFront à l'origine avant de passer à l'origine secondaire (dans le cas d'un groupe d'origine) ou de renvoyer une réponse d'erreur à l'utilisateur. Par défaut, CloudFront attend jusqu'à 30 secondes (3 tentatives de 10 secondes) avant de tenter de se connecter à l'origine secondaire ou de renvoyer une réponse d'erreur. Vous pouvez réduire ce délai en spécifiant moins de tentatives, un délai d'attente de connexion plus court, ou les deux.

Pour plus d'informations, consultez Contrôle des délais d'expiration et des tentatives de l'origine.

Délai de réponse de l'origine

Le délai de réponse de l'origine, également appelé délai d'attente des opérations de lecture depuis l'origine ou délai de demande à l'origine, s'applique aux deux valeurs suivantes :

  • Durée, en secondes, pendant laquelle CloudFront attend une réponse après avoir transféré une demande à l’origine.

  • Durée, en secondes, pendant laquelle CloudFront attend après avoir reçu un paquet d'une réponse provenant de l'origine et avant de recevoir le paquet suivant.

Le comportement de CloudFront dépend de la méthode HTTP utilisée dans la demande utilisateur :

  • Demandes GET et HEAD – Si l'origine ne répond pas ou cesse de répondre pendant la durée du délai de réponse, CloudFront annule la connexion. Si le nombre spécifié de tentatives de connexion de l'origine est supérieur à 1, CloudFront essayez à nouveau d'obtenir une réponse complète. CloudFront essaie jusqu'à 3 fois, selon la valeur du paramètre de tentatives de connexion de l'origine . Si l'origine ne répond pas lors de la dernière tentative, CloudFront ne réessaie pas tant qu'il ne reçoit pas une autre demande de contenu sur la même origine.

  • Demandes DELETE, OPTIONS, PATCH, PUT et POST – Si l'origine ne répond pas dans les 30 secondes, CloudFront annule la connexion et ne réessaye pas de contacter l'origine. Le client peut soumettre à nouveau la demande si nécessaire.

Pour de plus amples informations, y compris sur la manière de configurer le délai de réponse de l'origine, consultez Délai de réponse de l'origine.

Demandes simultanées pour le même objet (pics de trafic)

Lorsqu'un emplacement périphérique CloudFront reçoit une requête d'objet et que l'objet ne se trouve pas actuellement dans le cache ou que l'objet a expiré, CloudFront envoie immédiatement la requête à votre origine. En cas de pic de trafic (si des requêtes supplémentaires de même objet arrivent sur l'emplacement périphérique avant que votre origine réponde à la première requête), CloudFront s'interrompt brièvement avant de transmettre des requêtes supplémentaires pour l'objet à votre origine. Généralement, la réponse à la première demande arrive sur l'emplacement périphérique CloudFront avant la réponse à des demandes ultérieures. Cette courte pause contribue à réduire toute charge inutile sur votre serveur d'origine. Si les requêtes supplémentaires ne sont pas identiques parce que, par exemple, vous avez configuré CloudFront pour effectuer la mise en cache en fonction d'en-têtes de requête ou de cookies, CloudFront transmet toutes les requêtes uniques à votre origine.

En-tête d'agent utilisateur

Si vous souhaitez que CloudFront mette en cache différentes versions de vos objets en fonction de l'appareil grâce auquel un utilisateur visualise votre contenu, nous vous recommandons de configurer CloudFront pour transmettre un ou plusieurs des en-têtes suivants à votre origine personnalisée :

  • CloudFront-Is-Desktop-Viewer

  • CloudFront-Is-Mobile-Viewer

  • CloudFront-Is-SmartTV-Viewer

  • CloudFront-Is-Tablet-Viewer

En fonction de la valeur de l'en-tête User-Agent, CloudFront définit la valeur de ces en-têtes sur true ou false avant de réacheminer la requête vers votre origine. Si un périphérique tombe dans plusieurs catégories, il peut être possible de true. Par exemple, pour certaines tablettes, CloudFront peut être réglé CloudFront-Is-Mobile-Viewer et CloudFront-Is-Tablet-Viewer vers true. Pour plus d’informations sur la configuration CloudFront pour le cache basé sur les en-têtes de demande, voir Mise en cache de contenu basée sur des en-têtes de requêtes.

Vous pouvez configurer CloudFront de sorte qu'il mette en cache des objets selon les valeurs de l'en-tête User-Agent, mais cela n'est pas recommandé. L'en-tête User-Agent possède de nombreuses valeurs possibles, et la mise en cache selon ces valeurs entraînerait la mise en cache par CloudFront de beaucoup plus de demandes à votre origine.

Si vous ne configurez pas CloudFront pour qu'il mette en cache des objets en fonction des valeurs de l'en-tête User-Agent, CloudFront ajoute un en-tête User-Agent avec les valeurs suivantes avant de transmettre une demande à votre origine :

User-Agent = Amazon CloudFront

CloudFront ajoute cet en-tête, que la requête de l'utilisateur inclut un en-tête User-Agent ou non. Si la requête de l'utilisateur inclut un en-tête User-Agent, CloudFront le supprime.

Traitement des réponses de votre serveur d'origine personnalisée par CloudFront

Cette rubrique contient des informations sur la façon dont CloudFront traite les réponses provenant de votre origine personnalisée.

Réponses 100-Continue

Votre origine ne peut pas envoyer plus d'une réponse 100-Continue à CloudFront. Après la première réponse 100-Continue, CloudFront attend une réponse HTTP 200 OK. Si votre origine envoie une autre réponse 100-Continue après la première, CloudFront renvoie une erreur.

Caching

  • Assurez-vous que le serveur d'origine définit des valeurs valides et précises pour les champs d'en-tête Date et Last-Modified.

  • Si des demandes d'utilisateurs incluent les champs d'en-tête de demande If-Match ou If-None-Match, définissez le champ d'en-tête de réponse ETag. Si vous ne spécifiez pas une valeur ETag, CloudFront ignore les en-têtes If-Match ou If-None-Match suivants.

  • CloudFront respecte normalement un en-tête Cache-Control: no-cache dans la réponse de l'origine. Pour une exception, consultez Demandes simultanées pour le même objet (pics de trafic).

Demandes annulées

Si un objet n'est pas dans le cache périphérique et si un utilisateur met fin à une session (fermeture d'un navigateur par exemple) après que CloudFront a extrait l'objet de l'origine mais avant qu'il puisse fournir l'objet demandé, CloudFront ne met pas en cache l'objet dans l'emplacement périphérique.

Négociation de contenu

Si votre origine revient Vary:* dans la réponse, et si la valeur de TTL minimum pour le comportement de cache correspondant est 0, CloudFront cache l’objet mais transmet toujours chaque demande ultérieure de l’objet à l’origine pour confirmer que le cache contient la dernière version de l’objet. CloudFront n’inclut pas les en-têtes conditionnels, tels que If-None-Match ou If-Modified-Since. Par conséquent, votre origine renvoie l’objet à CloudFront en réponse à chaque demande.

Si votre origine renvoie Vary:* dans la réponse et si la valeur de Minimum TTL (Durée de vie minimale) pour le comportement de cache correspondant est n'importe quelle autre valeur, CloudFront traite l'en-tête Vary comme décrit dans En-têtes de réponse HTTP que CloudFront supprime ou remplace.

Cookies

Si vous activez les cookies pour un comportement de cache et si l'origine renvoie des cookies avec un objet, CloudFront met en cache l'objet et les cookies. Notez que cela réduit la capacité de mise en cache pour un objet. Pour plus d'informations, consultez Mise en cache de contenu basée sur des cookies,

Connexions TCP annulées

Si la connexion TCP entre CloudFront et votre origine est annulée alors que votre origine renvoie un objet à CloudFront, le comportement de CloudFront évoluera selon si votre origine incluait ou non un en-tête Content-Length dans la réponse :

  • En-tête Content-Length – CloudFront renvoie l'objet à l'utilisateur lorsqu'il obtient l'objet de votre origine. Cependant, si la valeur de l'en-tête Content-Length ne correspond pas à la taille de l'objet, CloudFront ne met pas l'objet en cache.

  • Codage de transfert : Bloc – CloudFront renvoie l’objet à la visionneuse à mesure qu’il obtient l’objet de votre origine. Cependant, si la réponse fragmentée n'est pas complète, CloudFront ne met pas l'objet en cache.

  • En-tête No Content-Length – CloudFront renvoie l'objet à l'utilisateur et le met en cache, mais l'objet peut ne pas être complet. Sans en-tête Content-Length, CloudFront ne peut pas déterminer si la connexion TCP a été est annulée délibérément ou par erreur.

Nous vous recommandons de configurer votre serveur HTTP pour ajouter un en-tête Content-Length afin d'empêcher CloudFront de mettre en cache des objets partiels.

En-têtes de réponse HTTP que CloudFront supprime ou remplace

CloudFront supprime ou met à jour les champs d'en-tête suivants avant de transmettre la réponse de votre origine à l'utilisateur :

  • Set-Cookie – Si vous configurez CloudFront pour transmettre les cookies, celui-ci transmet le champ d'en-tête Set-Cookie aux clients. Pour plus d'informations, consultez Mise en cache de contenu basée sur des cookies,

  • Trailer

  • Transfer-Encoding – Si votre origine renvoie ce champ d'en-tête, CloudFront définit la valeur sur chunked avant de renvoyer la réponse à l'utilisateur.

  • Upgrade

  • Vary – Notez bien ce qui suit :

    • Si vous configurez CloudFront pour transmettre des en-têtes spécifiques aux appareils à votre origine (CloudFront-Is-Desktop-Viewer, CloudFront-Is-Mobile-Viewer, CloudFront-Is-SmartTV-Viewer, CloudFront-Is-Tablet-Viewer) et que vous configurez votre origine pour renvoyer Vary:User-Agent à CloudFront, CloudFront renvoie Vary:User-Agent à l'utilisateur. Pour plus d'informations, consultez Configuration de la mise en cache en fonction du type d'appareil,

    • Si vous configurez votre origine pour inclure Accept-Encoding ou Cookie dans l'en-tête Vary, CloudFront inclut les valeurs dans la réponse à l'utilisateur.

    • Si vous configurez CloudFront pour transmettre une liste blanche d'en-têtes à votre origine et que vous configurez CloudFront pour renvoyer les noms d'en-tête à Vary dans l'en-tête Vary:Accept-Charset,Accept-Language (par exemple, CloudFront), &CF; renvoie l'en-tête Vary avec ces valeurs à l'utilisateur.

    • Pour en savoir plus sur la façon dont CloudFront traite une valeur * dans l'en-tête Vary, consultez Négociation de contenu.

    • Si vous configurez votre origine pour inclure d'autres valeurs dans l'en-tête Vary, CloudFront supprime les valeurs avant de renvoyer la réponse à l'utilisateur.

  • Via – CloudFront définit la valeur suivante dans la réponse à l'utilisateur :

    Via: http-version alphanumeric-string.cloudfront.net (CloudFront)

    Par exemple, si le client envoie une demande via HTTP/1.1, la valeur ressemble à ce qui suit :

    Via: 1.1 1026589cc7887e7a0dc7827b4example.cloudfront.net (CloudFront)

Taille maximale de fichier

La taille maximale d'un corps de réponse renvoyé par CloudFront à l'utilisateur est de 20 Go. Cette taille inclut les réponses de transfert fragmentées qui ne spécifient pas la valeur d'en-tête Content-Length.

Origine non disponible

Si votre serveur d'origine n'est pas disponible et que CloudFront obtient une requête d'objet figurant dans le cache périphérique mais ayant expiré (par exemple, parce que la période spécifiée dans la directive Cache-Control max-age est écoulée), CloudFront sert la version expirée de l'objet ou sert une page d'erreur personnalisée. Pour plus d'informations sur le comportement de CloudFront lorsque vous avez configuré des pages d'erreur personnalisées, consultez Traitement des erreurs par CloudFront lorsque vous avez configuré des pages d'erreur personnalisées.

Dans certains cas, un objet qui est rarement demandé est expulsé et n'est plus disponible dans le cache périphérique. CloudFront ne peut servir un objet qui a été expulsé.

Redirects

Si vous changez l'emplacement d'un objet sur le serveur d'origine, vous pouvez configurer votre serveur Web afin de rediriger les demandes vers le nouvel emplacement. Lorsque vous avez configuré la redirection, la première fois qu'un utilisateur soumet une requête d'objet, CloudFront envoie la requête à l'origine et l'origine répond avec une redirection (par exemple, 302 Moved Temporarily). CloudFront met en cache la redirection et la renvoie à l'utilisateur. CloudFront ne suit pas la redirection.

Vous pouvez configurer votre serveur Web afin de rediriger les demandes vers l'un des emplacements suivants :

  • La nouvelle URL de l'objet sur le serveur d'origine. Lorsque l'utilisateur suit la redirection vers la nouvelle URL, il contourne CloudFront et accède directement à l'origine. Par conséquent, nous vous recommandons de ne pas rediriger des demandes vers la nouvelle URL de l'objet sur l'origine.

  • La nouvelle URL CloudFront pour l'objet. Lorsque l'utilisateur soumet la requête qui contient la nouvelle URL CloudFront, CloudFront extrait l'objet du nouvel emplacement sur votre origine, le met en cache sur l'emplacement périphérique et renvoie l'objet à l'utilisateur. Les demandes suivantes pour l'objet seront servies par l'emplacement périphérique. Ceci évite la latence et la charge associées aux utilisateurs qui demandent l'objet à l'origine. Cependant, chaque nouvelle demande pour l'objet occasionne des frais pour deux demandes à CloudFront.

Encodage de transfert

CloudFront prend en charge uniquement la valeur chunked de l'en-tête Transfer-Encoding. Si votre origine retourne Transfer-Encoding: chunked, CloudFront renvoie l'objet au client lorsque l'objet est reçu sur l'emplacement périphérique et met l'objet en cache au format fragmenté pour les requêtes suivantes.

Si l'utilisateur fait une requête Range GET et que l'origine renvoie Transfer-Encoding: chunked, CloudFront renvoie l'objet entier à l'utilisateur au lieu de la plage demandée.

Nous vous recommandons d'utiliser un encodage fragmenté si la longueur du contenu de votre réponse ne peut pas être prédéterminé. Pour plus d'informations, consultez Connexions TCP annulées,