Transport des données
Compression HTTP : décoder un flux avant de contrôler le catalogue
Un transfert compressé et un fichier d’archive ne suivent pas nécessairement le même traitement. La recette doit préciser les octets reçus, le décodage effectué et le contenu finalement utilisé pour l’import.
Source et portée du repère
La RFC 9110 distingue le type de contenu des codages appliqués à la représentation. Content-Encoding indique les décodages à effectuer ; la référence décrit notamment gzip et la négociation des codages.
RFC 9110 : HTTP Semantics, Content-Encoding — consultée le . Sémantique HTTP de la RFC, sans promesse de compression sur un serveur donné. La méthode ne change aucun réglage de serveur ni de client du projet.
Les contrôles qui suivent constituent une méthode éditoriale de Performance Voyage. Ils ne rapportent aucune opération exécutée sur un compte fournisseur.
Décrire les étapes du transport à l’import
Inscrivez ce que le client demande, les métadonnées reçues et le contenu exposé au parseur. Une bibliothèque peut déjà décoder le flux ; cette étape doit être connue avant de demander un second décodage. Conservez type de contenu et codage comme deux observations distinctes. Le nom d’un fichier ou une extension ne remplace pas la lecture de ces métadonnées et du traitement effectif.
Comparer les volumes au bon moment
Mesurez les tailles utiles à la recette en précisant si elles concernent transport ou contenu décodé. Préparez des limites adaptées au traitement pour qu’une forte expansion ne devienne pas un succès apparent d’import. L’équipe doit aussi retrouver sur quels octets une empreinte ou un contrôle d’intégrité porte. Deux mesures prises à des étapes différentes ne sont pas comparables sans leur convention.
Organiser la reprise après erreur de décodage
Un flux interrompu, un codage inattendu et un JSON invalide ne sont pas le même échec. Gardez la dernière étape prouvée et le périmètre non appliqué au catalogue. Le relais doit savoir si la récupération a réussi mais le décodage échoué, ou si l’import a commencé. Le scénario utilise un jeu fictif ; il ne prescrit pas une nouvelle requête fournisseur ni une modification de configuration.
Deux cas fictifs à faire rapprocher
Le client décode déjà le corps
Scénario fictif : la bibliothèque retourne un texte exploitable tandis que l’import essaie encore de le décompresser. Faites retracer les étapes et leurs métadonnées avant de classer le cas comme fichier corrompu. La correction attendue explique à quel niveau le parseur reçoit le contenu.
Une empreinte compare deux étapes différentes
Scénario fictif : une empreinte annoncée porte sur le fichier compressé, mais le contrôle local utilise le texte décodé. Comparez les conventions et les références du jeu d’essai. Un désaccord de calcul ne prouve pas à lui seul une altération du catalogue.
Conserver les preuves et la prochaine décision
| Point | Preuve à retrouver | Contrôle proposé |
|---|---|---|
| Demande | Codages acceptés dans le scénario | Identifier la négociation prévue. |
| Métadonnées | Type et Content-Encoding reçus | Séparer format et transformation. |
| Client | Décodage déjà effectué ou attendu | Éviter une seconde transformation. |
| Volumes | Transport et contenu décodé | Nommer l’étape de chaque mesure. |
| Limites | Bornes du traitement prévu | Examiner une expansion importante. |
| Intégrité | Octets couverts par le contrôle | Comparer la même représentation. |
| Erreur | Transfert, décodage ou parsing | Garder la cause observée. |
| Reprise | Dernière étape prouvée et suite | Préserver le catalogue non appliqué. |
Le suivi décrit chaque étape et sa représentation avant de valider l’import. Taille, empreinte et résultat du parseur restent comparables parce que leur périmètre est explicite. Une erreur de décodage ne devient pas une mise à jour réussie du catalogue.
Erreurs à éviter
- Décompresser un contenu déjà décodé.
- Comparer des empreintes portant sur des octets différents.
- Confondre compression HTTP et fichier d’archive.
La fiche de contrôle permet de suivre les huit points. Le registre associé peut être préparé dans l’atelier avec des références fictives ou anonymisées.
Sources et périmètre des faits documentés
La date de consultation figure avec chaque référence. Les méthodes d’essai et recommandations de ce guide sont éditoriales ; les conditions d’accès et d’usage se vérifient dans la documentation actuelle.
- RFC 9110 : HTTP Semantics, Content-Encoding — Sémantique HTTP de la RFC, sans promesse de compression sur un serveur donné. La méthode ne change aucun réglage de serveur ni de client du projet. (consultée le )
Questions fréquentes
Questions utiles avant de décider
Content-Type indique-t-il la compression HTTP ?
Le type de contenu et les codages de représentation sont des informations distinctes. Retrouvez le traitement réellement appliqué.
Quel volume consigner ?
Précisez l’étape : transport, contenu décodé ou autre mesure utilisée par la recette.
Une différence d’empreinte prouve-t-elle une corruption ?
Comparez d’abord les octets et conventions couverts par chaque calcul.