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

Cloud Storage n'accepte pas le transcodage par décompression pour les objets compressés au format Brotli.

Transcodage par décompression

Le transcodage par décompression vous permet de stocker des versions compressées de fichiers dans Cloud Storage, ce qui réduit les coûts de stockage de données au repos, tout en continuant à diffuser le fichier directement au demandeur, sans compression. Cette méthode est utile, par exemple, lors de la diffusion de fichiers auprès des clients.

Pour que le transcodage par décompression se produise, 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 de l'objet incluent Content-Encoding: gzip.

Lorsqu'un objet répond à ces deux critères, il fait l'objet d'un transcodage par décompression lors de la diffusion et la réponse contenant l'objet ne contient pas d'en-tête Content-Encoding ou Content-Length.

Il existe deux méthodes pour empêcher le transcodage par décompression d'un objet qui est autrement éligible :

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

Empêcher le transcodage par décompression est utile, par exemple, si vous souhaitez réduire le coût ou le temps du transfert de données sortantes, ou si vous souhaitez vérifier que les objets téléchargés ont les sommes de contrôle crc32c/md5 prévues.

Points à prendre en compte

Tenez compte des points suivants lorsque vous utilisez le transcodage par décompression :

  • Le transcodage par décompression invalide la vérification d'intégrité sur les données renvoyées dans la réponse. En effet, le hachage stocké avec un objet représente les données dans leur état compressé, tandis que les données diffusées voient leur compression supprimée et, par conséquent, ont une valeur de hachage différente. Si les demandeurs de vos données s'appuient sur des sommes de contrôle pour la vérification de l'intégrité, vous ne devez pas utiliser le transcodage par décompression.

  • Le transcodage par décompression vous permet de stocker des objets dans Cloud Storage dans un état compressé, afin de réduire l'espace et les coûts. Cependant, les frais de téléchargement de l'objet sont basés sur sa taille décompressée, car il s'agit de la taille de l'objet diffusé.

  • Lorsqu'on y accède depuis un bucket installé sur Cloud Storage FUSE, les objets ne sont pas soumis au transcodage par décompression et sont lus comme étant compressés.

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-Typeet 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. Le fichier reçu par le client n'a donc pas la même somme de contrôle que celui importé et stocké dans Cloud Storage. Par conséquent, toutes les vérifications d'intégrité échouent.

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é. Par exemple, si vous avez un objet de 10 Go éligible au transcodage, mais que vous incluez l'en-tête Range: bytes=0-10000 dans la requête, vous recevez la totalité de cet objet.

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

Étape suivante