Transcoder des fichiers compressés au format gzip

Cette page traite de la conversion de fichiers vers et depuis un état compressé au format gzip. Elle comprend une présentation du transcodage et du comportement des fichiers compressés dans Cloud Storage, et des bonnes pratiques pour l'utilisation des métadonnées associées.

Transcoder avec gzip

La compression des données au format gzip qui permet généralement de réduire la taille d'un fichier. Cela signifie que le fichier peut être transféré plus rapidement et stocké en utilisant moins d'espace que s'il n'était pas compressé. La compression d'un fichier peut réduire à la fois les coûts et le temps de transfert. Dans Cloud Storage, le transcodage est la modification automatique de la compression d'un fichier avant sa diffusion auprès d'un demandeur. Lorsque le transcodage génère un fichier compressé au format gzip, ce fichier peut être considéré comme ayant fait l'objet d'une compression. D'autre part, lorsque le résultat est un fichier qui n'est plus compressé au format gzip, ce fichier peut être considéré comme ayant fait l'objet d'une décompression. Cloud Storage accepte le transcodage par décompression.

Transcodage par décompression

Si les fichiers sont stockés en tant qu'objets compressés au format gzip sur Cloud Storage, ils peuvent être automatiquement décompressés avant d'être envoyés à un demandeur : cela génère un fichier encodé à l'identique (en d'autres termes, un fichier non compressé). Le transcodage par décompression permet de réduire les coûts de stockage de l'objet dans Cloud Storage, mais transmet au demandeur le fichier lui-même, sans aucune compression. Cette méthode est utile, par exemple, lors de la diffusion de fichiers auprès des clients.

Pour pouvoir bénéficier du transcodage par décompression, un objet doit répondre à deux critères :

  1. Le fichier est compressé au format gzip lorsqu'il est stocké dans Cloud Storage.

  2. Les métadonnées associées incluent Content-Encoding: gzip.

Lorsqu'un objet répond à ces deux critères, il fait l'objet d'un transcodage par décompression à la demande ; dans ce cas, il est également diffusé sans en-tête Content-Encoding. Si vous souhaitez qu'un objet qui répond à ces deux critères soit diffusé dans son état compressé (par exemple, pour réduire le coût ou le temps de sortie), il existe deux méthodes d'empêcher le transcodage par décompression :

  • Si la requête d'objet comprend un en-tête Accept-Encoding: gzip, l'objet est diffusé tel quel dans cette requête spécifique et inclut un en-tête de réponse Content-Encoding: gzip.

  • Si le champ de métadonnées Cache-Control de l'objet est défini sur no-transform, l'objet est diffusé en tant qu'objet compressé dans toutes les requêtes suivantes, quels que soient les en-têtes Accept-Encoding.

Content-Type et Content-Encoding

Les éléments Content-Type et Content-Encoding se comportent de diverses manières lors du transcodage, et vous devez en tenir compte. Ces deux éléments correspondent à des métadonnées stockées avec un objet. Consultez la page Afficher et modifier des métadonnées d'objets pour obtenir des instructions détaillées sur l'ajout de métadonnées à des objets.

Content-Type doit être inclus dans toutes les importations et indique le type d'objet importé. Exemple :

Content-Type: text/plain

indique que l'objet importé est un fichier en texte brut. Aucun contrôle ne permet de garantir que l'élément Content-Type spécifié correspond bien à un objet importé. Toutefois, si vous spécifiez le type de façon incorrecte, les demandeurs recevront au mieux une importation ne répondant pas à leurs attentes, et des comportements inattendus pourraient se produire.

Content-Encoding est un élément facultatif et peut, si vous le souhaitez, être inclus dans l'importation de fichiers compressés. Exemple :

Content-Encoding: gzip

indique que l'objet importé est compressé au format gzip. Comme avec Content-Type, aucun contrôle ne garantit que l'élément Content-Encoding spécifié est réellement appliqué à l'objet importé. Cependant, la spécification incorrecte de l'encodage d'un objet pourrait entraîner un comportement inattendu lors de requêtes d'importation ultérieures.

Bonnes pratiques

  • Lors de l'importation d'un objet compressé au format gzip, la méthode recommandée pour définir les métadonnées consiste à spécifier Content-Type et Content-Encoding. Par exemple, pour un fichier compressé en texte brut, procédez comme suit :

    Content-Type: text/plain
    Content-Encoding: gzip
    

    Cette méthode fournit le plus d'informations sur l'état de l'objet à toute personne y accédant. L'objet devient également éligible au transcodage par décompression lors de son téléchargement ultérieur, ce qui permet aux applications clientes de gérer correctement la sémantique de type Content-Type.

  • Vous pouvez également importer l'objet et définir l'élément Content-Type de manière à indiquer la compression, sans spécifier AUCUN élément Content-Encoding. Exemple :

    Content-Type: application/gzip
    

    Cependant, dans ce cas, seul le fait que l'objet est compressé au format gzip est immédiatement connu ; aucune information concernant le type d'objet sous-jacent n'est présente. De plus, l'objet n'est pas éligible au transcodage par décompression.

Pratiques déconseillées

  • Même s'il est possible de le faire, vous ne devez pas importer un fichier compressé au format gzip en omettant de spécifier la nature compressée du fichier. Par exemple, pour un fichier en texte brut compressé au format gzip, vous devez éviter de ne définir que Content-Type: text/plain. Cela représenterait de manière erronée l'état de l'objet tel qu'il sera transmis à un demandeur.

  • De même, vous ne devez pas importer d'objets en omettant l'élément Content-Type, même si un élément Content-Encoding est inclus. Cela pourrait entraîner la définition de Content-Type sur une valeur par défaut, mais également le rejet de la requête en fonction de la manière dont l'importation est effectuée.

Pratiques incorrectes

  • Vous ne devez pas configurer les métadonnées pour signaler de manière redondante la compression de l'objet :

    Content-Type: application/gzip
    Content-Encoding: gzip
    

    Cela implique que vous importez un objet compressé au format gzip qui a été une seconde fois compressé au format gzip, alors que ce n'est généralement pas le cas. Si vous envisagez réellement de compresser un fichier deux fois, consultez la section Utiliser gzip sur des objets compressés ci-après. Lorsque le transcodage par décompression se produit sur un tel objet spécifié de manière incorrecte, l'objet est diffusé comme étant encodé à l'identique. Cependant, les demandeurs pensent avoir reçu un objet auquel une couche de compression est toujours associée. Ainsi, les tentatives de décompression de l'objet échouent.

  • De même, un fichier qui n'est pas compressé au format gzip ne doit pas être importé avec l'en-tête Content-Encoding: gzip. Si c'est le cas, l'objet semble être éligible au transcodage, mais lorsque des requêtes pour l'objet sont envoyées, les tentatives de transcodage échouent.

Utiliser gzip sur des objets compressés

Certains objets, tels que de nombreux fichiers vidéo, audio et image, sans parler des fichiers gzip eux-mêmes, sont déjà compressés. L'utilisation de gzip sur de tels objets n'offre pratiquement aucun avantage : dans la plupart des cas, l'objet est agrandi en raison de la surcharge gzip. Pour cette raison, l'utilisation de gzip sur un contenu compressé est généralement déconseillée et peut entraîner des comportements indésirables.

Par exemple, Cloud Storage autorise l'importation et le stockage d'objets "compressés deux fois", c'est-à-dire des objets compressés au format gzip, mais ayant également un élément Content-Type sous-jacent qui est lui-même compressé. Cependant, Cloud Storage n'autorise pas la diffusion d'objets dans un état de compression double à moins que leurs métadonnées Cache-Control n'incluent no-transform. Au lieu de cela, il supprime le niveau de compression externe gzip, supprime l'en-tête de réponse Content-Encoding et diffuse l'objet résultant. Cela se produit même pour les requêtes contenant Accept-Encoding: gzip.

Utiliser l'en-tête Range

Lors du transcodage, si la requête d'objet comprend un en-tête Range, cet en-tête est ignoré sans notification. Cela signifie que les requêtes de contenu partiel ne sont pas satisfaites et que la réponse diffuse l'objet entier demandé. Ce comportement est dû au fait qu'il est impossible de sélectionner une plage dans un fichier compressé sans d'abord décompresser le fichier dans son intégralité : chaque requête associée à une partie d'un fichier est accompagnée de la décompression de l'ensemble du fichier, potentiellement volumineux, ce qui utilise les ressources de façon inefficace. Vous devez avoir connaissance de ce comportement et éviter d'utiliser l'en-tête Range lors du transcodage, car des frais sont facturés pour la transmission de l'objet entier et pas uniquement de la plage demandée. Pour en savoir plus sur le comportement de réponse autorisé associé aux requêtes contenant des en-têtes Range, consultez la spécification.

Si des requêtes contenant des en-têtes Range sont nécessaires, vous devez vous assurer que le transcodage ne se produit pas pour l'objet demandé. Vous pouvez y parvenir en choisissant les propriétés appropriées lors de l'importation des objets. Par exemple, les requêtes de plage pour des objets avec Content-Type: application/gzip et sans Content-Encoding sont effectuées comme demandé.

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…

Besoin d'aide ? Consultez notre page d'assistance.