Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Ajouter, supprimer ou remplacer du contenu CloudFront diffusé Cette section explique comment vous assurer que vous CloudFront pouvez accéder au contenu que vous souhaitez proposer à vos visiteurs, comment spécifier les objets de votre site Web ou de votre application, et comment supprimer ou remplacer du contenu. **Topics** + [Ajoutez et accédez à du contenu qui CloudFront diffuse](#AddingObjects) + [Utiliser la gestion des versions de fichiers pour mettre à jour ou supprimer le contenu d'une distribution CloudFront](UpdatingExistingObjects.md) + [Personnalisez le format d'URL pour les fichiers dans CloudFront](LinkFormat.md) + [Spécification d’un objet racine par défaut](DefaultRootObject.md) + [Invalidation de fichiers pour supprimer du contenu](Invalidation.md) + [Diffusion de fichiers compressés](ServingCompressedFiles.md) ## Ajoutez et accédez à du contenu qui CloudFront diffuse Lorsque vous CloudFront souhaitez distribuer du contenu (objets), vous ajoutez des fichiers à l'une des origines que vous avez spécifiées pour la distribution et vous exposez un CloudFront lien vers les fichiers. Un emplacement CloudFront périphérique ne récupère pas les nouveaux fichiers depuis une origine tant que l'emplacement périphérique n'a pas reçu les demandes des utilisateurs les concernant. Pour de plus amples informations, veuillez consulter [Comment CloudFront diffuse le contenu](HowCloudFrontWorks.md). Lorsque vous ajoutez un fichier que vous CloudFront souhaitez distribuer, assurez-vous de l'ajouter à l'un des compartiments Amazon S3 spécifiés dans votre distribution ou, pour une origine personnalisée, à un répertoire du domaine spécifié. De plus vérifiez que le modèle de chemin dans le comportement de cache applicable envoie les demandes à l’origine correcte. Par exemple, imaginons qu’un modèle de chemin pour un comportement de cache soit `*.html`. Si aucun autre comportement de cache n'est configuré pour transférer les demandes vers cette origine, seuls `*.html` les fichiers CloudFront seront transférés. Dans ce scénario, par exemple, vous ne CloudFront distribuerez jamais les fichiers .jpg que vous téléchargez vers l'origine, car vous n'avez pas créé de comportement de cache incluant les fichiers .jpg. CloudFront les serveurs ne déterminent pas le type MIME des objets qu'ils servent. Lorsque vous chargez un fichier dans votre origine, nous vous recommandons de définir le champ d’en-tête `Content-Type` pour celui-ci. # Utiliser la gestion des versions de fichiers pour mettre à jour ou supprimer le contenu d'une distribution CloudFront Pour mettre à jour le contenu existant CloudFront configuré pour être distribué pour vous, nous vous recommandons d'utiliser un identifiant de version dans les noms de fichiers ou de dossiers. Cela vous permet de contrôler la gestion du contenu CloudFront diffusé. ## Mise à jour des fichiers existants à l’aide de noms de fichiers versionnés Lorsque vous mettez à jour des fichiers existants dans une CloudFront distribution, nous vous recommandons d'inclure une sorte d'identifiant de version dans le nom de vos fichiers ou dans le nom de votre répertoire afin de mieux contrôler votre contenu. Cet identifiant peut être un horodatage, un numéro séquentiel ou toute autre méthode permettant de faire la distinction entre deux versions du même objet. Par exemple, au lieu de nommer un fichier graphique image.jpg, vous pouvez l’appeler image\$11.jpg. Lorsque vous souhaitez commencer à servir une nouvelle version du fichier, vous appellerez alors le nouveau fichier image\$12.jpg et vous mettrez à jour les liens de votre application Web ou site Web pour pointer sur image\$12.jpg. Sinon, vous pouvez placer tous les graphiques dans un répertoire images\$1v1, et lorsque vous souhaitez commencer à servir des nouvelles versions d’un ou plusieurs graphiques, vous créez un nouveau répertoire images\$1v2, et vous mettez à jour vos liens pour pointer sur ce répertoire. Avec le versionnement, vous n'avez pas à attendre l'expiration d'un objet avant de CloudFront commencer à proposer une nouvelle version de celui-ci, et vous n'avez pas à payer pour l'invalidation de l'objet. Même si vous versionnez vos fichiers, nous vous recommandons de définir une date d’expiration. Pour plus d’informations, consultez [Gestion de la durée de conservation de contenu dans le cache (expiration)](Expiration.md). **Note** La spécification de noms de fichier ou de répertoire versionnés n’est pas liée à la gestion des versions d’objets Amazon S3. ## Supprimez le contenu pour CloudFront ne pas le distribuer Vous pouvez supprimer des fichiers de votre origine que vous ne souhaitez plus voir inclus dans votre distribution CloudFront. Cependant, le contenu du cache périphérique CloudFront continuera à être diffusé aux spectateurs jusqu'à ce que les fichiers expirent. Si vous souhaitez supprimer un fichier immédiatement, vous devez effectuer l’une des actions suivantes : + **Utilisez la gestion des versions de fichiers.** Lorsque vous utilisez le versionnement, les différentes versions d'un fichier ont des noms différents que vous pouvez utiliser dans votre CloudFront distribution, afin de modifier le fichier renvoyé aux lecteurs. Pour de plus amples informations, veuillez consulter [Mise à jour des fichiers existants à l’aide de noms de fichiers versionnés](#ReplacingObjects). + **Invalidez le fichier.** Pour de plus amples informations, veuillez consulter [Invalidation de fichiers pour supprimer du contenu](Invalidation.md). # Personnalisez le format d'URL pour les fichiers dans CloudFront Une fois que vous avez configuré votre origine avec les objets (contenu) que vous souhaitez proposer CloudFront à vos visiteurs, vous devez utiliser le code correct URLs pour référencer ces objets dans le code de votre site Web ou de votre application afin qu'il CloudFront puisse les servir. Le nom de domaine que vous utilisez dans URLs les objets de vos pages Web ou dans votre application Web peut être l'un des suivants : + Le nom de domaine, par exemple`d111111abcdef8.cloudfront.net`, qui est attribué CloudFront automatiquement lorsque vous créez une distribution + Votre propre nom de domaine, comme `example.com` Par exemple, vous pouvez utiliser l'une des méthodes suivantes URLs pour renvoyer le fichier `image.jpg` : `https://d111111abcdef8.cloudfront.net/images/image.jpg` `https://example.com/images/image.jpg` Vous utilisez le même format d’URL que vous stockiez le contenu dans des compartiments Amazon S3 ou dans une origine personnalisée, comme l’une de vos propres serveurs web. **Note** Le format d’URL dépend en partie de la valeur que vous spécifiez pour **Chemin d’origine** dans votre distribution. Cette valeur indique CloudFront le chemin du répertoire principal pour vos objets. Pour plus d’informations sur la définition du chemin d’accès d’origine lorsque vous créez une distribution, consultez [Chemin d’origine](DownloadDistValuesOrigin.md#DownloadDistValuesOriginPath). Pour plus d’informations sur les formats d’URL, consultez les sections suivantes. ## Utilisation de votre propre nom de domaine (exemple.com) Au lieu d'utiliser le nom de domaine par défaut qui CloudFront vous est attribué lorsque vous créez une distribution, vous pouvez [ajouter un autre nom de domaine](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesCNAME) plus facile à utiliser, par exemple`example.com`. En configurant votre propre nom de domaine avec CloudFront, vous pouvez utiliser une URL comme celle-ci pour les objets de votre distribution : `https://example.com/images/image.jpg` Si vous prévoyez d'utiliser le protocole HTTPS entre les utilisateurs et CloudFront, consultez[Utilisation de noms de domaines alternatifs et HTTPS](using-https-alternate-domain-names.md). ## Utilisez une barre oblique (/) dans URLs Lorsque vous spécifiez URLs des répertoires dans votre CloudFront distribution, choisissez de toujours utiliser une barre oblique ou de ne jamais utiliser de barre oblique de fin. Par exemple, choisissez uniquement l'un des formats suivants pour tous vos URLs : `https://d111111abcdef8.cloudfront.net/images/` `https://d111111abcdef8.cloudfront.net/images` **Pourquoi est-ce important ?** Les deux formats fonctionnent pour créer des liens vers CloudFront des objets, mais la cohérence peut aider à éviter les problèmes lorsque vous souhaitez invalider un répertoire ultérieurement. CloudFront stocke les URLs données exactement telles qu'elles sont définies, y compris les barres obliques finales. Donc, si votre format n'est pas cohérent, vous devrez invalider le répertoire URLs avec et sans barre oblique, pour vous assurer que le répertoire sera CloudFront supprimé. Ce n’est pas pratique d’invalider les deux formats d’URL et cela peut entraîner des coûts supplémentaires. En effet, si vous devez doubler les invalidations pour couvrir les deux types de cas URLs, vous risquez de dépasser le nombre maximum d'invalidations gratuites autorisé pour le mois. Et si tel est le cas, vous devrez payer pour toutes les invalidations, même s'il n'existe qu'un seul format pour chaque URL de répertoire dans CloudFront. ## Créer du contenu signé URLs pour des contenus restreints Si vous souhaitez restreindre l'accès à du contenu, vous pouvez créer une signature URLs. Par exemple, si vous souhaitez distribuer votre contenu uniquement aux utilisateurs authentifiés, vous pouvez créer des URLs contenus valides uniquement pour une période spécifiée ou disponibles uniquement à partir d'une adresse IP spécifiée. Pour de plus amples informations, veuillez consulter [Diffusez du contenu privé avec des cookies signés URLs et signés](PrivateContent.md). # Spécification d’un objet racine par défaut Vous pouvez configurer CloudFront pour renvoyer un objet spécifique (l'objet racine par défaut) lorsqu'un utilisateur (spectateur) demande l'URL racine de votre distribution au lieu de demander un objet dans votre distribution. Vous pouvez utiliser un objet racine par défaut pour éviter d’exposer le contenu de votre distribution. **Contents** + [Comment spécifier un objet racine par défaut](#DefaultRootObjectHowToDefine) + [Fonctionnement de l'objet racine par défaut](#DefaultRootObjectHow) + [Comment CloudFront fonctionne si vous ne définissez pas d'objet racine](#DefaultRootObjectNotSet) ## Comment spécifier un objet racine par défaut Pour éviter d’exposer le contenu de votre distribution ou de renvoyer une erreur, spécifiez un objet racine par défaut pour votre distribution. Vous pouvez spécifier le nom exact du fichier ou le chemin d’accès au fichier. Par exemple, si votre objet racine est un fichier `index.html`, vous pouvez spécifier ce nom de fichier. Si votre fichier `index.html` se trouve dans un autre dossier, spécifiez plutôt le chemin, tel que `exampleFolderName/index.html`. Si vous définissez un chemin pour l’objet racine par défaut, les demandes des utilisateurs adressées à l’URL racine de la distribution renverront le fichier spécifié à partir de ce chemin. Vous pouvez utiliser un chemin de fichier pour disposer de plus de flexibilité dans l’organisation de votre contenu à l’origine, car votre objet racine par défaut peut se trouver dans un dossier plutôt qu’à la racine. **Pour spécifier un objet racine par défaut pour votre distribution** 1. Chargez l’objet racine par défaut sur l’origine sur laquelle pointe votre distribution. Le fichier peut être de n'importe quel type pris en charge par CloudFront. Pour obtenir la liste des contraintes relatives au nom du fichier, consultez l'`DefaultRootObject`élément dans [DistributionConfig](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_DistributionConfig.html)le *Amazon CloudFront API Reference*. **Note** Si le nom de fichier de l'objet racine par défaut est trop long ou contient un caractère non valide, CloudFront renvoie l'erreur`HTTP 400 Bad Request - InvalidDefaultRootObject`. En outre, CloudFront met le code en cache pendant 10 secondes (par défaut) et écrit les résultats dans les journaux d'accès. 1. Vérifiez que les autorisations associées à l'objet accordent au CloudFront moins un accès en lecture. Pour plus d’informations sur les autorisations Amazon S3, consultez [Gestion des autorisations d’accès à vos ressources Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-access-control.html) dans le *Guide du développeur Amazon Simple Storage Service*. 1. Mettez à jour votre distribution pour qu'elle fasse référence à l'objet racine par défaut à l'aide de la CloudFront console ou de l' CloudFront API. Pour spécifier un objet racine par défaut à l'aide de la CloudFront console : 1. Connectez-vous à la CloudFront console AWS Management Console et ouvrez-la à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home). 1. Dans le volet supérieur de la liste de distributions, sélectionnez la distribution à mettre à jour. 1. Dans le volet **Paramètres**, sous l’onglet **Général**, sélectionnez **Modifier**. 1. Dans la boîte de dialogue **Modifier les paramètres**, dans le champ **Objet racine par défaut**, entrez le nom de fichier ou le chemin de l’objet racine par défaut. **Astuce** Votre chaîne ne peut pas commencer par une barre oblique (`/`). Indiquez uniquement le nom de l’objet ou le chemin menant à cet objet. Par exemple, utilisez `index.html` ou `exampleFolderName/index.html`. Si vous spécifiez `/exampleFolderName/index.html` ou `/index.html`, vous risquez d’obtenir une [erreur 403 Accès refusé](http-403-permission-denied.md). 1. Sélectionnez **Enregistrer les modifications**. Pour mettre à jour votre configuration à l'aide de l' CloudFront API, spécifiez une valeur pour l'`DefaultRootObject`élément dans votre distribution. Pour plus d'informations sur l'utilisation de l' CloudFront API pour spécifier un objet racine par défaut, consultez [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)le *Amazon CloudFront API Reference*. 1. Vérifiez que vous avez activé l’objet racine par défaut en demandant votre URL racine. Si votre navigateur n’affiche pas l’objet racine par défaut, effectuez les opérations suivantes : 1. Vérifiez que votre distribution est entièrement déployée en consultant l'état de votre distribution dans la CloudFront console. 1. Répétez les étapes 2 et 3 pour vérifier que vous avez accordé les autorisations correctes et que vous avez correctement mis à jour la configuration de votre distribution pour spécifier l’objet racine par défaut. ## Fonctionnement de l'objet racine par défaut Imaginons que la requête suivante pointe vers l’objet `image.jpg`: `https://d111111abcdef8.cloudfront.net/image.jpg` En revanche, la requête suivante pointe vers l’URL racine de la même distribution plutôt que sur un objet particulier, comme dans le premier exemple : `https://d111111abcdef8.cloudfront.net/` Lorsque vous définissez un objet racine par défaut, une demande d’utilisateur final qui appelle la racine de votre distribution renvoie l’objet racine par défaut. Par exemple, si vous désignez le fichier `index.html` comme objet racine par défaut, une demande pour : `https://d111111abcdef8.cloudfront.net/` Renvoie: `https://d111111abcdef8.cloudfront.net/index.html` **Note** CloudFront ne détermine pas si une URL comportant plusieurs barres obliques (`https://d111111abcdef8.cloudfront.net///`) est équivalente à. `https://d111111abcdef8.cloudfront.net/` C'est votre serveur d'origine qui effectue cette comparaison. Si vous définissez un objet racine par défaut, une demande d'utilisateur final pour un sous-répertoire de votre distribution ne renvoie pas l'objet racine par défaut. Supposons, par exemple, qu'`index.html`il s'agisse de votre objet racine par défaut et qu'il CloudFront reçoive une demande d'utilisateur final pour le `install` répertoire de votre CloudFront distribution : `https://d111111abcdef8.cloudfront.net/install/` CloudFront ne renvoie pas l'objet racine par défaut même si une copie de `index.html` apparaît dans le `install` répertoire. Toutefois, si vous avez spécifié un *chemin vers* votre objet racine par défaut, (`install/index.html`) CloudFront renverra l'objet racine par défaut pour les demandes de l'utilisateur final concernant le répertoire `install` Si vous configurez votre distribution pour autoriser toutes les méthodes HTTP prises en charge par CloudFront, l'objet racine par défaut s'applique à toutes les méthodes. Par exemple, si votre objet racine par défaut est index.php et que vous écrivez dans votre application pour envoyer une `POST` demande à la racine de votre domaine (https://example.com), CloudFront envoie la demande à https://example.com /index.php. Le comportement des objets racines CloudFront par défaut est différent de celui des documents d'index Amazon S3. Lorsque vous configurez un compartiment Amazon S3 comme site web et que vous spécifiez le document d’index, Amazon S3 renvoie le document d’index même si un utilisateur demande un sous-répertoire du compartiment. (Une copie du document d’index doit apparaître dans chaque sous-répertoire.) Pour plus d’informations sur la configuration de compartiments Amazon S3 en tant que sites web et sur les documents d’index, consultez le chapitre [Hébergement de sites web sur Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/WebsiteHosting.html) dans le *Guide de l’utilisateur Amazon Simple Storage Service*. **Important** N'oubliez pas qu'un objet racine par défaut s'applique uniquement à votre CloudFront distribution. Vous devez quand-même gérer la sécurité pour votre origine. Par exemple, si vous utilisez une origine Amazon S3, vous devez tout de même configurer votre compartiment Amazon S3 de ACLs manière appropriée pour garantir le niveau d'accès que vous souhaitez pour votre compartiment. ## Comment CloudFront fonctionne si vous ne définissez pas d'objet racine Si vous ne définissez pas un objet racine par défaut, des demandes pour la racine de votre distribution sont transmises à votre serveur d’origine. Si vous utilisez une origine Amazon S3, l’un des éléments suivants peut être renvoyé : + **Liste du contenu de votre compartiment Amazon S3 — Dans l'une** des conditions suivantes, le contenu de votre origine est visible par tous ceux qui ont accès CloudFront à votre distribution : + Votre compartiment n’est pas correctement configuré. + Les autorisations Amazon S3 sur le compartiment associé à votre distribution et sur les objets du compartiment accordent l’accès à *quiconque*. + Un utilisateur final accède à votre origine à l’aide de l’URL racine de votre origine. + **Liste des contenus privés de votre origine** : si vous configurez votre origine en tant que distribution privée (vous êtes le seul à CloudFront y avoir accès), le contenu du compartiment Amazon S3 associé à votre distribution est visible par toute personne disposant des informations d'identification nécessaires pour accéder à votre distribution CloudFront. Dans ce cas, les utilisateurs ne peuvent pas accéder à vos contenus via l’URL racine de votre origine. Pour plus d’informations sur la distribution de contenus privés, consultez [Diffusez du contenu privé avec des cookies signés URLs et signés](PrivateContent.md). + `Error 403 Forbidden`— CloudFront renvoie cette erreur si les autorisations sur le compartiment Amazon S3 associé à votre distribution ou les autorisations sur les objets de ce compartiment interdisent l'accès à CloudFront tout le monde. # Invalidation de fichiers pour supprimer du contenu Si vous devez supprimer un fichier des caches CloudFront Edge avant son expiration, vous pouvez effectuer l'une des opérations suivantes : + Invalidez le fichier des caches périphériques. La prochaine fois qu'un utilisateur demande le fichier, il CloudFront retourne à l'origine pour récupérer la dernière version du fichier. + Utilisez la gestion des versions de fichiers pour offrir une version différente du fichier dont le nom diffère. Pour de plus amples informations, veuillez consulter [Mise à jour des fichiers existants à l’aide de noms de fichiers versionnés](UpdatingExistingObjects.md#ReplacingObjects). **Topics** + [Choix entre invalider des fichiers existants et utiliser des noms de fichier versionnés](#Invalidation_Expiration) + [Détermination des fichiers à invalider](invalidation-access-logs.md) + [Ce que vous devez savoir lorsque vous invalidez des fichiers](invalidation-specifying-objects.md) + [Invalidation de fichiers](Invalidation_Requests.md) + [Nombre maximum de requêtes d’invalidation simultanées](InvalidationLimits.md) + [Paiement pour une invalidation de fichier](PayingForInvalidation.md) ## Choix entre invalider des fichiers existants et utiliser des noms de fichier versionnés Pour contrôler les versions de fichiers qui sont offerts à partir de votre distribution, vous pouvez invalider des fichiers ou leur attribuer des noms de fichier versionnés. Si vous souhaitez mettre souvent vos fichiers à jour, nous vous recommandons d’utiliser principalement la gestion des versions de fichiers pour les raisons suivantes : + La gestion des versions vous permet de contrôler quel fichier est renvoyé par une requête même lorsque l’utilisateur dispose d’une version en cache en local ou derrière un proxy de mise en cache d’entreprise. Si vous invalidez le fichier, l’utilisateur pourrait continuer de voir l’ancienne version tant qu’elle n’est pas arrivée à expiration dans ces caches. + CloudFront les journaux d'accès incluent les noms de vos fichiers, de sorte que la gestion des versions facilite l'analyse des résultats des modifications apportées aux fichiers. + La gestion des versions offre un moyen d’offrir des versions différentes de fichiers à des utilisateurs différents. + La gestion des versions simplifie la restauration par progression et la restauration entre les révisions de fichier. + La gestion des versions est moins chère. Vous devez toujours payer pour CloudFront transférer les nouvelles versions de vos fichiers vers des emplacements périphériques, mais vous n'avez pas à payer pour invalider des fichiers. Pour plus d’informations sur la gestion des versions de fichiers, consultez [Mise à jour des fichiers existants à l’aide de noms de fichiers versionnés](UpdatingExistingObjects.md#ReplacingObjects). # Détermination des fichiers à invalider Si vous souhaitez invalider plusieurs fichiers, par exemple tous les fichiers d’un répertoire ou tous les fichiers commençant par les mêmes caractères, vous pouvez inclure le caractère générique `*` à la fin du chemin d’invalidation. Pour plus d’informations sur l’utilisation du caractère générique `*`, consultez [Invalidation paths](invalidation-specifying-objects.md#invalidation-specifying-objects-paths). Pour invalider des fichiers, vous pouvez indiquer le chemin pour des fichiers individuels ou un chemin qui se termine par le caractère générique `*` qui peut s’appliquer à un ou plusieurs fichiers, comme illustré dans les exemples suivants : + `/images/image1.jpg` + `/images/image*` + `/images/*` Si vous souhaitez invalider certains fichiers mais que vos utilisateurs n'ont pas forcément à accès à chaque fichier sur votre origine, vous pouvez déterminer quels fichiers les utilisateurs ont demandés à CloudFront et n'invalider que ces fichiers. Pour déterminer les fichiers demandés par les utilisateurs, activez la journalisation des CloudFront accès. Pour plus d’informations sur les journaux d’accès, consultez [Journaux d'accès (journaux standard)](AccessLogs.md). # Ce que vous devez savoir lorsque vous invalidez des fichiers Lorsque vous indiquez un fichier à invalider, consultez les informations suivantes : **Sensibilité à la casse** Les chemins d’invalidation sont sensibles à la casse. Par exemple, `/images/image.jpg` et `/images/Image.jpg` désignent deux fichiers différents. **Modification de l’URI à l’aide d’une fonction Lambda** Si votre CloudFront distribution déclenche une fonction Lambda lors d'événements de demande du lecteur, et si la fonction modifie l'URI du fichier demandé, nous vous recommandons d'invalider les deux URIs pour supprimer le fichier des CloudFront caches périphériques : + L’URI de la demande utilisateur + L’URI une fois que la fonction l’a modifié **Example Exemple** Supposons que votre fonction Lambda modifie l’URI d’un fichier, en remplaçant : `https://d111111abcdef8.cloudfront.net/index.html` par un URI qui inclut un répertoire de langue : `https://d111111abcdef8.cloudfront.net/en/index.html` Pour invalider le fichier, vous devez spécifier les chemins suivants : + `/index.html` + `/en/index.html` Pour plus d’informations, consultez [Invalidation paths](#invalidation-specifying-objects-paths). **Objet racine par défaut** Pour invalider l’objet racine (fichier) par défaut, spécifiez le chemin tout comme le chemin pour tout autre fichier. Pour de plus amples informations, veuillez consulter [Fonctionnement de l'objet racine par défaut](DefaultRootObject.md#DefaultRootObjectHow). **Transmettre des cookies** Si vous avez configuré CloudFront pour transférer les cookies vers votre source, les caches CloudFront périphériques peuvent contenir plusieurs versions du fichier. Lorsque vous invalidez un fichier, toutes CloudFront les versions mises en cache du fichier sont invalidées, quels que soient les cookies associés. Vous ne pouvez pas invalider de façon sélective certaines versions et pas d’autres en fonction des cookies associés. Pour plus d’informations, consultez [Mise en cache de contenu basée sur des cookies](Cookies.md). **Transmettre des en-têtes** Si vous avez configuré CloudFront pour transférer une liste d'en-têtes vers votre origine et pour la mettre en cache en fonction des valeurs des en-têtes, les caches CloudFront périphériques peuvent contenir plusieurs versions du fichier. Lorsque vous invalidez un fichier, CloudFront invalide chaque version mise en cache du fichier, quelles que soient les valeurs des en-têtes. Vous ne pouvez pas invalider de façon sélective certaines versions et pas d’autres en fonction de valeurs d’en-têtes. (Si vous configurez CloudFront pour transférer tous les en-têtes vers votre origine, vos fichiers CloudFront ne sont pas mis en cache.) Pour de plus amples informations, veuillez consulter [Mise en cache de contenu basée sur des en-têtes de demandes](header-caching.md). **Transmission de chaînes de requête** Si vous avez configuré CloudFront pour transférer les chaînes de requête vers votre origine, vous devez inclure les chaînes de requête lors de l'invalidation de fichiers, comme indiqué dans les exemples suivants : + `/images/image.jpg?parameter1=a` + `/images/image.jpg?parameter1=b` Si les requêtes client incluent cinq chaînes de requête différentes pour le même fichier, vous pouvez soit invalider le fichier cinq fois (une fois par chaîne de requête), soit utiliser le caractère générique \$1 dans le chemin d’invalidation, comme illustré dans l’exemple suivant : `/images/image.jpg*` Pour plus d’informations sur l’utilisation de caractères génériques dans le chemin d’invalidation, consultez [Invalidation paths](#invalidation-specifying-objects-paths). Pour plus d’informations sur les chaînes de requête, consultez [Mise en cache de contenu basée sur les paramètres de chaîne de requête](QueryStringParameters.md). Pour déterminer quelles chaînes de requête sont utilisées, vous pouvez activer la journalisation des accès CloudFront. Pour de plus amples informations, veuillez consulter [Journaux d'accès (journaux standard)](AccessLogs.md). **Maximum autorisé** Pour plus d’informations sur le nombre maximum d’invalidations autorisées, consultez [Nombre maximum de requêtes d’invalidation simultanées](InvalidationLimits.md). **Fichiers Microsoft Smooth Streaming** Vous ne pouvez pas invalider des fichiers multimédias au format Microsoft Smooth Streaming lorsque vous avez activé Smooth Streaming pour le comportement de cache correspondant. **Caractères autres qu’ASCII ou caractères non sûrs dans le chemin** Si le chemin inclut des caractères autres qu'ASCII ou non sûrs, tels que définis dans la [RFC 1738](https://tools.ietf.org/html/rfc1738), encodez ces caractères dans l'URL. N'encodez pas d'URL pour les autres caractères du chemin, car cela CloudFront n'invalidera pas l'ancienne version du fichier mis à jour. N'utilisez pas le `~` personnage sur votre chemin. CloudFront ne prend pas en charge ce caractère pour les invalidations, qu'il soit codé en URL ou non. **Chemins d’invalidation** Le chemin est relatif par rapport à la distribution. Par exemple, pour invalider le fichier à l’adresse `https://d111111abcdef8.cloudfront.net/images/image2.jpg`, vous devez spécifier `/images/image2.jpg`. Dans la [console CloudFront](https://console.aws.amazon.com/cloudfront/v4/home), vous pouvez omettre la barre oblique de début dans le chemin, comme ci-après : `images/image2.jpg`. Lorsque vous utilisez directement l' CloudFront API, les chemins d'invalidation doivent commencer par une barre oblique. Vous pouvez également invalider simultanément plusieurs fichiers à l’aide du caractère générique `*`. Le caractère générique `*`, qui remplace 0 caractère ou plus, doit être le dernier caractère dans le chemin d’invalidation. Pour utiliser des caractères génériques (\$1) lors de l’invalidation, vous devez placer le caractère générique à la fin du chemin. Les astérisques (\$1) insérés ailleurs sont traités comme une correspondance de caractères littérale au lieu d’une invalidation par un caractère générique. Si vous utilisez le AWS Command Line Interface (AWS CLI) pour invalider des fichiers et que vous spécifiez un chemin qui inclut le `*` caractère générique, vous devez utiliser des guillemets (`"`) autour du chemin, par exemple. `"/*"` La longueur maximale d’un chemin est de 4 000 caractères. **Example Exemple : chemins d’invalidation** + Pour invalider tous les fichiers dans un répertoire : `/`*directory-path*`/*` + Pour invalider un répertoire, tous ses sous-répertoires, et tous les fichiers de ce répertoire et ces sous-répertoires : `/`*directory-path*`*` + Pour invalider tous les fichiers qui ont le même nom mais des extensions de nom de fichier différentes, comme logo.jpg, logo.png et logo.gif : `/`*directory-path*`/`*file-name*`.*` + Pour invalider tous les fichiers d’un répertoire dont le nom de fichier commence par les mêmes caractères (par exemple, tous les fichiers pour une vidéo au format HLS), quelle que soit l’extension du nom de fichier : `/`*directory-path*`/`*initial-characters-in-file-name*`*` + Lorsque vous configurez CloudFront le cache en fonction des paramètres de chaîne de requête et que vous souhaitez invalider toutes les versions d'un fichier : `/`*directory-path*`/`*file-name*`.`*file-name-extension*`*` + Pour invalider tous les fichiers dans une distribution : `/*` Pour plus d’informations sur l’invalidation de fichiers si vous utilisez une fonction Lambda pour modifier l’URI, consultez [Changing the URI Using a Lambda Function](#invalidation-lambda-at-edge). Si le chemin d’invalidation est un répertoire et que vous n’avez pas adopté une méthode standardisée pour spécifier les répertoires, avec ou sans barre oblique de fin (/), nous vous recommandons d’invalider le répertoire avec et sans barre oblique de fin, par exemple, `/images` et `/images/`. **Signé URLs** Si vous utilisez Signed URLs, invalidez un fichier en incluant uniquement la partie de l'URL située avant le point d'interrogation (?). # Invalidation de fichiers Vous pouvez utiliser la CloudFront console pour créer et exécuter une invalidation, afficher la liste des invalidations que vous avez soumises précédemment et afficher des informations détaillées sur une invalidation individuelle. Vous pouvez également copier une invalidation existante, modifier la liste des chemins de fichier et exécuter l’invalidation modifiée. Vous ne pouvez pas supprimer d’invalidations de la liste. **Contents** + [Invalidation de fichiers](#invalidating-objects-console) + [Copie, modification et réexécution d’une invalidation existante](#invalidating-objects-copy-console) + [Annulation des invalidations](#canceling-invalidations) + [Liste des invalidations](#listing-invalidations-console) + [Affichage des informations sur une invalidation](#invalidation-details-console) ## Invalidation de fichiers Pour invalider des fichiers à l'aide de la CloudFront console, procédez comme suit. ------ #### [ Console ] **Pour invalider des fichiers (console)** 1. Connectez-vous à la CloudFront console AWS Management Console et ouvrez-la à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home). 1. Choisissez la distribution pour laquelle vous voulez invalider des fichiers. 1. Choisissez l’onglet **Invalidations**. 1. Sélectionnez **Créer une invalidation**. 1. Pour les fichiers que vous voulez invalider, entrez un chemin d’invalidation par ligne. Pour plus d’informations sur la spécification de chemins d’invalidation, consultez [Ce que vous devez savoir lorsque vous invalidez des fichiers](invalidation-specifying-objects.md). **Important** Indiquez les chemins de fichier avec soin. Vous ne pouvez pas annuler une demande d’invalidation après l’avoir commencée. 1. Sélectionnez **Créer une invalidation**. ------ #### [ CloudFront API ] *Pour en savoir plus sur l'invalidation d'objets et l'affichage d'informations sur les invalidations, consultez les rubriques suivantes dans le manuel Amazon API Reference : CloudFront * + [CreateInvalidation](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateInvalidation.html) + [ListInvalidations](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_ListInvalidations.html) + [GetInvalidation](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_GetInvalidation.html) **Note** Si vous utilisez le AWS Command Line Interface (AWS CLI) pour invalider des fichiers et que vous spécifiez un chemin qui inclut le `*` caractère générique, vous devez placer le chemin entre guillemets (`"`), comme dans l'exemple suivant : ``` aws cloudfront create-invalidation --distribution-id distribution_ID --paths "/*" ``` ------ ## Copie, modification et réexécution d’une invalidation existante Vous pouvez copier une invalidation que vous avez créée précédemment, mettre à jour la liste des chemins d’invalidation d’objet et exécuter l’invalidation mise à jour. Vous ne pouvez pas copier une invalidation existante, mettre à jour la liste des chemins d’invalidation, puis enregistrer l’invalidation mise à jour sans l’exécuter. **Important** Si vous copiez une invalidation toujours en cours, mettez à jour la liste des chemins d'invalidation, puis exécutez l'invalidation mise à jour, CloudFront sans arrêter ni supprimer l'invalidation que vous avez copiée. Si des chemins d'invalidation apparaissent dans l'original et dans la copie, CloudFront nous essaierons d'invalider les fichiers deux fois, et les deux invalidations seront prises en compte dans votre nombre maximum d'invalidations gratuites pour le mois. Si vous avez déjà atteint le nombre maximal d’invalidations gratuites, les deux invalidations vous seront facturées pour chaque fichier. Pour de plus amples informations, veuillez consulter [Nombre maximum de requêtes d’invalidation simultanées](InvalidationLimits.md). **Pour copier, modifier et réexécuter une invalidation existante** 1. Connectez-vous à la CloudFront console AWS Management Console et ouvrez-la à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home). 1. Sélectionnez la distribution qui contient l’invalidation à copier. 1. Choisissez l’onglet **Invalidations**. 1. Sélectionnez l’invalidation que vous souhaitez copier. Si vous n’êtes pas sûr de l’invalidation à copier, vous pouvez choisir une invalidation et sélectionner **Afficher les détails** pour afficher des informations détaillées sur cette invalidation. 1. Choisissez **Copier vers un nouvel élément**. 1. Mettez à jour la liste des chemins d’invalidation la cas échéant. 1. Sélectionnez **Créer une invalidation**. ## Annulation des invalidations Lorsque vous soumettez une demande d'invalidation à CloudFront, CloudFront transfère la demande à tous les emplacements périphériques en quelques secondes, et chaque emplacement périphérique commence immédiatement à traiter l'invalidation. De ce fait, vous ne pouvez pas annuler une invalidation après l’avoir soumise. ## Liste des invalidations Vous pouvez afficher la liste des 100 dernières invalidations que vous avez créées et exécutées pour une distribution à l'aide de la CloudFront console. Si vous souhaitez obtenir une liste de plus de 100 invalidations, utilisez l’opération d’API `ListInvalidations`. Pour plus d'informations, consultez [ListInvalidations](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_ListInvalidations.html)le *Amazon CloudFront API Reference*. **Pour répertorier des invalidations** 1. Connectez-vous à la CloudFront console AWS Management Console et ouvrez-la à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home). 1. Sélectionnez la distribution pour laquelle vous voulez afficher une liste d’invalidations. 1. Choisissez l’onglet **Invalidations**. **Note** Vous ne pouvez pas supprimer d’invalidations de la liste. ## Affichage des informations sur une invalidation Vous pouvez afficher des informations détaillées sur une invalidation, notamment l’ID de distribution, l’ID d’invalidation, le statut de l’invalidation, la date et l’heure auxquelles l’invalidation a été créée, et une liste complète des chemins d’invalidation. **Pour afficher des informations sur une invalidation** 1. Connectez-vous à la CloudFront console AWS Management Console et ouvrez-la à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home). 1. Sélectionnez la distribution qui contient l’invalidation pour laquelle vous souhaitez afficher des informations détaillées. 1. Choisissez l’onglet **Invalidations**. 1. Choisissez l’ID d’invalidation applicable ou sélectionnez l’ID d’invalidation, puis sélectionnez **Afficher les détails**. # Nombre maximum de requêtes d’invalidation simultanées Si vous invalidez des fichiers individuellement, il est possible que des demandes d’invalidation concernant jusqu’à 3 000 fichiers par distribution soient en cours en même temps. Il peut s’agir d’une demande d’invalidation concernant jusqu’à 3 000 fichiers, de 3 000 demandes concernant chacune un fichier, ou d’une autre combinaison ne dépassant pas 3 000 fichiers. Par exemple, vous pouvez soumettre 30 demandes d’invalidation invalidant 100 fichiers chacune. Tant que toutes les 30 demandes d’invalidation sont encore en cours, vous ne pouvez pas soumettre d’autres demandes d’invalidation. Si vous dépassez le maximum, CloudFront renvoie un message d'erreur. Si vous utilisez le caractère générique \$1, vous pouvez lancer en même temps des demandes concernant jusqu’à 15 chemins d’invalidation. Vous pouvez également lancer en même temps des demandes d’invalidation concernant jusqu’à 3 000 fichiers individuels par distribution, la limite concernant les demandes d’invalidation avec caractères génériques autorisées étant indépendante de la limite applicable à l’invalidation de fichiers individuels. # Paiement pour une invalidation de fichier Les premiers 1 000 chemins d’invalidation que vous soumettez par mois sont gratuits ; vous paierez pour chaque chemin d’invalidation au-delà de 1 000 au cours d’un mois. Un chemin d’invalidation peut être un fichier unique (comme `/images/logo.jpg`) ou plusieurs fichiers (comme `/images/*`). Un chemin qui inclut le `*` caractère générique est considéré comme un chemin, même s'il entraîne CloudFront l'invalidation de milliers de fichiers. Le maximum de 1 000 chemins d’invalidation gratuits par mois s’applique au nombre total de chemins d’invalidation pour toutes les distributions que vous créez avec un Compte AWS. Par exemple, si vous utilisez le Compte AWS `john@example.com` pour créer trois distributions et que vous soumettez 600 chemins d'invalidation pour *chaque distribution* au cours d'un mois donné (pour un total de 1 800 chemins d'invalidation), la différence entre le nombre total de chemins d'invalidation et la limite de 1 000 voies d'invalidation gratuites vous AWS sera facturée. Dans cet exemple, AWS vous facturerait 800 chemins d’invalidation pour ce mois-là. Les frais pour soumettre un chemin d’invalidation sont les mêmes quel que soit le nombre de fichiers que vous invalidez : un seul fichier (`/images/logo.jpg`) ou tous les fichiers associés à une distribution (`/*`). Étant donné que la facturation est appliquée par chemin dans une demande d’invalidation, regrouper plusieurs chemins dans une même demande ne change rien : chaque chemin est comptabilisé individuellement pour la facturation. Pour plus d'informations sur les tarifs d'invalidation, consultez [Amazon CloudFront Pricing](https://aws.amazon.com/cloudfront/pricing/). Pour plus d’informations sur les chemins d’invalidation, consultez [Invalidation paths](invalidation-specifying-objects.md#invalidation-specifying-objects-paths). # Diffusion de fichiers compressés Lorsque les objets demandés sont compressés, les téléchargements peuvent être plus rapides, parce que les objets sont plus petits (dans certains cas, inférieurs à un quart de la taille de l'objet original). Des téléchargements plus rapides peuvent accélérer le rendu des pages Web pour vos utilisateurs, en particulier pour JavaScript les fichiers CSS. En outre, le coût du transfert de CloudFront données est basé sur la quantité totale de données diffusées. La diffusion d’objets compressés peut être moins coûteux que la diffusion d’objets non compressés. **Topics** + [Configurer CloudFront pour compresser des objets](#compressed-content-cloudfront-configuring) + [Comment fonctionne CloudFront la compression](#compressed-content-cloudfront-how-it-works) + [Conditions de compression](#compressed-content-cloudfront-notes) + [Types de fichiers qui CloudFront compressent](#compressed-content-cloudfront-file-types) + [Conversion de l'en-tête `ETag`](#compressed-content-cloudfront-etag-header) ## Configurer CloudFront pour compresser des objets CloudFront Pour configurer la compression des objets, mettez à jour le comportement du cache que vous souhaitez utiliser pour les objets compressés. **Pour configurer CloudFront la compression d'objets (console)** 1. Connectez-vous à la [console CloudFront](https://console.aws.amazon.com/cloudfront/v4/home). 1. Choisissez votre distribution, puis le **Comportement** à modifier. 1. Pour le paramètre **Compresser automatiquement les objets**, choisissez **Oui**. 1. Utilisez une [politique de cache](controlling-the-cache-key.md) pour spécifier les paramètres de mise en cache et activez les formats de compression **Gzip** et **Brotli**. **Remarques** Vous devez utiliser des [politiques de cache](controlling-the-cache-key.md) pour utiliser la compression Brotli. Brotli ne prend pas en charge les anciens paramètres de cache. Pour activer la compression à l'aide de l'[CloudFront](https://docs.aws.amazon.com/cloudfront/latest/APIReference/Welcome.html)API [CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cloudfront-distribution-cachebehavior.html)ou de l'API`Compress`, définissez `EnableAcceptEncodingBrotli` les paramètres`EnableAcceptEncodingGzip`, sur`true`. Pour comprendre comment CloudFront compresse les objets, reportez-vous à la section suivante. ## Comment fonctionne CloudFront la compression 1. Un utilisateur demande un objet. L'utilisateur inclut l'en-tête HTTP `Accept-Encoding` dans la demande et les valeurs d'en-tête incluent `gzip`, `br` ou les deux. Cela signifie qu'il prend en charge les objets compressés. Lorsque le visualiseur supporte à la fois Gzip et Brotli, CloudFront il utilise Brotli. **Note** Les navigateurs web Chrome et Firefox prennent en charge la compression Brotli uniquement lorsque la demande est envoyée en HTTPS. Ils ne prennent pas en charge Brotli avec les demandes HTTP. 1. À l'emplacement périphérique, CloudFront recherche dans le cache une copie compressée de l'objet demandé. 1. Selon que l'objet compressé se trouve dans le cache ou non, CloudFront effectue l'une des opérations suivantes : + Si l'objet compressé est déjà dans le cache, CloudFront envoie l'objet au visualiseur et ignore les étapes restantes. + Si l'objet compressé ne se trouve pas dans le cache, CloudFront transmet la demande à l'origine. **Note** Si une copie non compressée de l'objet se trouve déjà dans le cache, vous CloudFront pouvez l'envoyer au visualiseur sans transmettre la demande à l'origine. Par exemple, cela peut se produire lorsque la [compression a CloudFront été précédemment ignorée](#compression-skipped). Dans ce cas, met en CloudFront cache l'objet non compressé et continue de le servir jusqu'à ce que l'objet expire, soit expulsé ou soit invalidé. 1. Si l'origine renvoie un objet compressé (comme indiqué par l'`Content-Encoding`en-tête de la réponse HTTP), CloudFront envoie l'objet compressé au visualiseur, l'ajoute au cache et ignore les étapes restantes. CloudFront ne compresse pas à nouveau l'objet. 1. Si l'origine renvoie un objet non compressé CloudFront sans l'`Content-Encoding`en-tête dans la réponse HTTP, CloudFront elle détermine si l'objet peut être compressé. Pour de plus amples informations, veuillez consulter [Conditions de compression](#compressed-content-cloudfront-notes). 1. Si l'objet peut être compressé CloudFront , compressez-le, envoyez-le au visualiseur, puis ajoutez-le au cache. 1. S'il y a des demandes ultérieures du spectateur pour le même objet, CloudFront renvoie la première version mise en cache. Par exemple, si un utilisateur demande un objet spécifique mis en cache utilisant la compression Gzip et que l’utilisateur *accepte* le format Gzip, les demandes ultérieures pour ce même objet renverront toujours la version Gzip, même si l’utilisateur accepte à la fois Brotli et Gzip. Certaines origines personnalisées peuvent également compresser des objets. Votre origine est peut-être en mesure de compresser des objets qui CloudFront ne le sont pas. Pour de plus amples informations, veuillez consulter [Types de fichiers qui CloudFront compressent](#compressed-content-cloudfront-file-types). ## Conditions de compression La liste suivante fournit plus d'informations sur les scénarios dans lesquels les objets CloudFront ne sont pas compressés. **La demande utilise HTTP 1.0** Si une demande CloudFront utilise le protocole HTTP 1.0, CloudFront supprime l'`Accept-Encoding`en-tête et ne compresse pas l'objet dans la réponse. **En-tête de demande `Accept-Encoding`** Si l'`Accept-Encoding`en-tête est absent de la demande du visualiseur, ou s'il ne contient pas `gzip` ou `br` ne contient pas de valeur, l'objet CloudFront n'est pas compressé dans la réponse. Si l'`Accept-Encoding`en-tête inclut des valeurs supplémentaires telles que`deflate`, les CloudFront supprime avant de transmettre la demande à l'origine. Lorsqu'il CloudFront est [configuré pour compresser des objets](#compressed-content-cloudfront-configuring), il inclut automatiquement l'`Accept-Encoding`en-tête dans la clé de cache et dans les demandes d'origine. **Le contenu est déjà mis en cache lorsque vous configurez CloudFront pour compresser des objets** CloudFront compresse les objets lorsqu'il les extrait de l'origine. Lorsque vous configurez CloudFront pour compresser des objets, CloudFront cela ne compresse pas les objets déjà mis en cache dans des emplacements périphériques. En outre, lorsqu'un objet mis en cache expire dans un emplacement périphérique et CloudFront transmet une autre demande pour l'objet à votre origine, CloudFront cela ne compresse pas l'objet lorsque votre origine renvoie un code d'état HTTP 304. Cela signifie que l’emplacement périphérique dispose déjà de la dernière version de l’objet. Si vous souhaitez CloudFront compresser des objets déjà mis en cache dans des emplacements périphériques, vous devez invalider ces objets. Pour de plus amples informations, veuillez consulter [Invalidation de fichiers pour supprimer du contenu](Invalidation.md). **L'origine est déjà configurée pour compresser les objets** Si vous configurez CloudFront pour compresser des objets et que l'origine compresse également des objets, l'origine doit inclure un `Content-Encoding` en-tête. Cet en-tête indique CloudFront que l'objet est déjà compressé. Lorsqu'une réponse provenant d'une origine inclut l'`Content-Encoding`en-tête, CloudFront elle ne compresse pas l'objet, quelle que soit la valeur de l'en-tête. CloudFrontenvoie la réponse au spectateur et met en cache l'objet à l'emplacement périphérique. **Types de fichiers qui CloudFront compressent** Pour obtenir la liste complète, consultez [Types de fichiers qui CloudFront compressent](#compressed-content-cloudfront-file-types). **Taille des objets qui CloudFront compressent** CloudFront compresse les objets dont la taille est comprise entre 1 000 et 10 000 000 octets. **En-tête `Content-Length`** L'origine doit inclure un `Content-Length` en-tête dans la réponse, qui CloudFront permet de déterminer si la taille de l'objet se situe dans la plage de CloudFront compression. Si l'`Content-Length`en-tête est absent, contient une valeur non valide ou contient une valeur en dehors de la plage de tailles qui CloudFront compresse, CloudFront cela ne compresse pas l'objet. Pour plus d'informations sur le CloudFront traitement des objets de grande taille pouvant dépasser la plage de tailles, consultez[Comment CloudFront traite les demandes partielles pour un objet (plage GETs)](RangeGETs.md). **Code d'état HTTP de la réponse** CloudFront compresse les objets uniquement lorsque le code d'état HTTP de la réponse est `200``403`, ou`404`. **La réponse n'a pas de corps** Lorsque la réponse HTTP de l'origine n'a pas de corps, il n'y a rien CloudFront à compresser. **En-tête `ETag`** CloudFront modifie parfois l'`ETag`en-tête de la réponse HTTP lorsqu'elle compresse des objets. Pour de plus amples informations, veuillez consulter [Conversion de l'en-tête `ETag`](#compressed-content-cloudfront-etag-header). **CloudFront ignore la compression** CloudFront compresse les objets au mieux. Dans de rares cas, CloudFront ignore la compression d'un objet en cas de CloudFront forte charge de trafic. CloudFront prend cette décision en fonction de divers facteurs, y compris la capacité de l'hôte. Si la compression CloudFront d'un objet est ignorée, il met en cache l'objet non compressé et continue de le servir aux utilisateurs jusqu'à ce que l'objet expire, soit expulsé ou soit invalidé. ## Types de fichiers qui CloudFront compressent Si vous configurez CloudFront pour compresser des objets, compresse CloudFront uniquement les objets dont l'en-tête de `Content-Type` réponse contient l'une des valeurs suivantes : + `application/dash+xml` + `application/eot` + `application/font` + `application/font-sfnt` + `application/javascript` + `application/json` + `application/opentype` + `application/otf` + `application/pdf` + `application/pkcs7-mime` + `application/protobuf` + `application/rss+xml` + `application/truetype` + `application/ttf` + `application/vnd.apple.mpegurl` + `application/vnd.mapbox-vector-tile` + `application/vnd.ms-fontobject` + `application/wasm` + `application/xhtml+xml` + `application/xml` + `application/x-font-opentype` + `application/x-font-truetype` + `application/x-font-ttf` + `application/x-httpd-cgi` + `application/x-javascript` + `application/x-mpegurl` + `application/x-opentype` + `application/x-otf` + `application/x-perl` + `application/x-ttf` + `font/eot` + `font/opentype` + `font/otf` + `font/ttf` + `image/svg+xml` + `text/css` + `text/csv` + `text/html` + `text/javascript` + `text/js` + `text/plain` + `text/richtext` + `text/tab-separated-values` + `text/xml` + `text/x-component` + `text/x-java-source` + `text/x-script` + `vnd.apple.mpegurl` ## Conversion de l'en-tête `ETag` Lorsque l'objet décompressé depuis l'origine inclut un en-tête `ETag` HTTP valide et fort, et qu'il CloudFront compresse l'objet, convertit CloudFront également la valeur d'`ETag`en-tête forte en valeur faible `ETag` et renvoie la `ETag` valeur faible au visualiseur. Les utilisateurs peuvent stocker la valeur `ETag` faible et l'utiliser pour envoyer des demandes conditionnelles avec l'en-tête HTTP `If-None-Match`. Cela permet aux utilisateurs et à l'origine de traiter les versions compressées et non compressées d'un objet comme sémantiquement équivalentes, ce qui réduit les transferts de données inutiles. CloudFront Une valeur d’en-tête `ETag` valide et forte commence et se termine par des guillemets doubles (`"`). Pour convertir la valeur `ETag` forte en valeur faible, CloudFront ajoute les caractères `W/` au début de la valeur `ETag` forte. Lorsque l'objet de l'origine inclut une faible valeur d'`ETag`en-tête (une valeur qui commence par les caractères`W/`), CloudFront ne modifie pas cette valeur et la renvoie au visualiseur telle qu'elle a été reçue de l'origine. Lorsque l'objet de l'origine inclut une valeur d'`ETag`en-tête non valide (la valeur ne commence pas par `"` ou par`W/`), CloudFront supprime l'`ETag`en-tête et renvoie l'objet au visualiseur sans l'en-tête de `ETag` réponse. Pour plus d’informations, consultez les pages suivantes dans les documents web MDN : + [Directives](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag#Directives) (en-tête HTTP `ETag`) + [Validation faible](https://developer.mozilla.org/en-US/docs/Web/HTTP/Conditional_requests#Weak_validation) (requêtes conditionnelles HTTP) + [En-tête HTTP If-None-Match](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-None-Match)