Formateur d’en-têtes HTTP

Convertir entre les formats brut et clé/valeur des en-têtes

HTTP Headers

Formatted Output

Enter HTTP headers to format and analyze

Le formateur d'en-têtes HTTP convertit entre du texte brut d'en-têtes HTTP et des représentations structurées clé-valeur. Il vous permet d'analyser des en-têtes issus de la sortie de curl -v, des outils de développement du navigateur ou de captures réseau sous forme éditable, puis de les reconstruire en syntaxe HTTP valide. Collez un bloc d'en-têtes bruts comme Content-Type: application/json\nAuthorization: Bearer eyJ... et obtenez un tableau structuré et propre que vous pouvez modifier et exporter.

Comprendre les en-têtes HTTP

Les en-têtes HTTP sont les métadonnées qui accompagnent chaque requête et chaque réponse sur le web. Ils indiquent au serveur quel contenu le client accepte, comment authentifier la requête, combien de temps mettre la réponse en cache, et des dizaines d'autres détails qui contrôlent le déroulement de la transaction HTTP. Si vous avez déjà ouvert les outils de développement du navigateur et regardé l'onglet Réseau, vous avez vu des en-têtes -- ce sont les paires clé-valeur Content-Type, Authorization, Cache-Control et autres listées sous chaque requête.

Pour le travail de développement quotidien, vous avez rarement besoin de penser au formatage des en-têtes car votre client HTTP ou votre framework le gère automatiquement. Le formatage devient un problème lorsque vous devez déplacer des en-têtes entre différents outils. Vous pourriez copier des en-têtes depuis Chrome DevTools et avoir besoin de les coller dans une collection Postman. Ou vous récupérez la sortie verbeuse de curl -v et devez extraire uniquement les en-têtes de réponse sans les préfixes < . Ou vous rédigez de la documentation API et devez présenter les en-têtes sous forme d'objet JSON propre plutôt que de texte brut. Chaque outil attend un format légèrement différent, et le reformatage manuel est fastidieux et source d'erreurs.

Ce formateur gère la conversion dans les deux sens. En mode analyse, il accepte des en-têtes bruts de n'importe quelle source courante -- outils de développement du navigateur, sortie curl verbeuse avec les préfixes > et < , captures tcpdump ou Wireshark, ou texte simple Clé: Valeur -- et produit un tableau structuré ou une sortie JSON. En mode construction, il prend des objets JSON, des données séparées par des tabulations ou des paires clé-valeur une par ligne et produit des en-têtes HTTP bruts correctement formatés avec les conventions de casse et les fins de ligne appropriées. Le résultat est constitué d'en-têtes prêts à être utilisés dans l'outil ou la configuration dont vous avez besoin.

Comment analyser des en-têtes HTTP bruts

  1. Collez les en-têtes HTTP bruts provenant de la sortie curl, des outils de développement du navigateur ou d'une capture de paquets dans le champ de saisie.
  2. Cliquez sur Parse pour extraire chaque en-tête dans un tableau structuré nom-valeur.
  3. Modifiez les valeurs individuelles selon vos besoins.
  4. Copiez la sortie structurée au format JSON ou en paires clé-valeur.

Comment construire des en-têtes HTTP à partir de données clé-valeur

  1. Saisissez les en-têtes en JSON ({"Content-Type": "application/json"}), en paires Clé: Valeur séparées par des retours à la ligne, ou en données séparées par des tabulations.
  2. Cliquez sur Build pour générer des en-têtes HTTP bruts correctement formatés.
  3. Copiez la sortie pour l'utiliser dans votre client HTTP, votre configuration serveur ou votre documentation.

Exemples de formatage d'en-têtes HTTP

Analyse de la sortie curl

Entrée (en-têtes bruts de curl -v) :

Content-Type: application/json; charset=utf-8
X-Request-ID: 8f14e45f-ceea-367f-a27f-4eb04ef4e
Cache-Control: public, max-age=3600
Set-Cookie: session=abc123; Path=/; HttpOnly
X-RateLimit-Remaining: 98

Sortie analysée :

Nom de l'en-têteValeur
Content-Typeapplication/json; charset=utf-8
X-Request-ID8f14e45f-ceea-367f-a27f-4eb04ef4e
Cache-Controlpublic, max-age=3600
Set-Cookiesession=abc123; Path=/; HttpOnly
X-RateLimit-Remaining98

Construction à partir de JSON

Entrée :

{
  "Authorization": "Bearer eyJhbGciOiJIUzI1NiIs...",
  "Content-Type": "application/json",
  "Accept": "application/json",
  "X-Custom-Header": "my-value"
}

Sortie (en-têtes bruts) :

Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
Content-Type: application/json
Accept: application/json
X-Custom-Header: my-value

Quand utiliser le formateur d'en-têtes HTTP

  • Copie d'en-têtes entre outils -- Convertissez les en-têtes du format Postman vers la syntaxe curl ou inversement sans reformatage manuel.
  • Modification d'ensembles complexes d'en-têtes -- Analysez un bloc volumineux d'en-têtes dans une vue structurée où les valeurs individuelles sont faciles à trouver et modifier.
  • Documentation d'API -- Convertissez des captures d'en-têtes bruts en JSON propre pour inclusion dans la documentation d'API et les fichiers README.
  • Comparaison de configurations -- Analysez les en-têtes de deux environnements différents dans le même format structuré pour une comparaison côte à côte.
  • Débogage de problèmes réseau -- Extrayez et organisez les en-têtes à partir de captures de paquets ou de logs de proxy pour analyse.
  • Migration de serveur -- Convertissez les en-têtes entre formats de configuration lors du passage d'un serveur web ou CDN à un autre.

Structure des en-têtes HTTP

Les en-têtes HTTP suivent un format simple Nom: Valeur défini dans la RFC 7230, mais les en-têtes en conditions réelles présentent plusieurs subtilités que le formateur gère.

Conventions de nommage des en-têtes

Les noms d'en-têtes sont insensibles à la casse selon la spécification HTTP. Content-Type, content-type et CONTENT-TYPE désignent tous le même en-tête. Le formateur conserve la casse originale lors de l'analyse et utilise la casse standard (par ex. Content-Type) lors de la construction.

En-têtes multi-valeurs

Certains en-têtes apparaissent plusieurs fois dans une réponse, et la spécification HTTP définit comment les combiner :

  • Les en-têtes basés sur des listes comme Cache-Control, Accept et Via peuvent être combinés avec des virgules : Cache-Control: no-cache, no-store.
  • Set-Cookie est un cas particulier -- Plusieurs en-têtes Set-Cookie doivent rester séparés et ne peuvent pas être joints par des virgules.
  • Les en-têtes pliés (désormais obsolètes en HTTP/1.1) utilisaient un espace en début de ligne pour continuer une valeur sur la ligne suivante.

Fins de ligne

HTTP/1.1 exige des fins de ligne \r\n (CRLF) entre les en-têtes. Le formateur accepte en entrée les fins de ligne Unix (\n), Windows (\r\n) ou mixtes, et produit une sortie conforme à la spécification avec CRLF lors de la construction.

Catégories courantes d'en-têtes

CatégorieEn-têtesFonction
Négociation de contenuAccept, Accept-Language, Accept-EncodingLe client indique au serveur les formats préférés
AuthentificationAuthorization, WWW-Authenticate, Proxy-AuthorizationIdentité et contrôle d'accès
CacheCache-Control, ETag, If-None-Match, If-Modified-SinceComportement et validation du cache
SécuritéStrict-Transport-Security, Content-Security-Policy, X-Frame-OptionsPolitiques de sécurité du navigateur
CORSAccess-Control-Allow-Origin, Access-Control-Allow-MethodsRègles d'accès cross-origin
Limitation de débitX-RateLimit-Limit, X-RateLimit-Remaining, Retry-AfterContrôles d'utilisation de l'API

Conseils pratiques pour travailler avec les en-têtes HTTP

Lors du débogage de problèmes API, la première chose à vérifier est si l'en-tête Content-Type correspond au format du corps. Envoyer un corps JSON avec Content-Type: application/x-www-form-urlencoded (ou pire, aucun Content-Type) est l'une des causes les plus courantes d'erreurs 400 Bad Request. Le serveur essaie d'analyser le corps selon le type de contenu déclaré, et lorsque le format ne correspond pas, l'analyse échoue. Ce formateur vous permet d'inspecter rapidement tous les en-têtes ensemble pour repérer les incohérences d'un coup d'oeil.

Un autre problème fréquent est la duplication d'en-têtes. Lorsque vous configurez des en-têtes à plusieurs niveaux -- code applicatif, reverse proxy, CDN -- il est facile de se retrouver avec des en-têtes en double qui entrent en conflit. Par exemple, votre application pourrait définir Cache-Control: private tandis que votre CDN ajoute Cache-Control: public, max-age=3600. Le comportement dépend de la couche qui l'emporte, et le résultat est souvent différent de ce que vous attendiez. Analysez les en-têtes de réponse réels et recherchez les doublons pour détecter ces conflits de configuration rapidement.

Lorsque vous travaillez avec des en-têtes de sécurité comme Content-Security-Policy ou Strict-Transport-Security, le formateur vous aide à vérifier que les valeurs sont syntaxiquement correctes avant de les déployer. Une directive CSP malformée peut casser votre site entier en bloquant des ressources légitimes, et un includeSubDomains manquant sur HSTS peut laisser les sous-domaines non protégés. Analysez l'en-tête, examinez chaque directive séparément, et testez en mode report-only avant d'appliquer.

Questions fréquentes

Les noms d'en-têtes HTTP sont-ils sensibles à la casse ?

Non. La RFC 7230 spécifie que les noms de champs d'en-tête sont insensibles à la casse. Content-Type et content-type sont le même en-tête. Cependant, HTTP/2 exige des noms d'en-têtes en minuscules, donc le formateur peut optionnellement mettre tous les noms en minuscules pour la compatibilité HTTP/2.

Comment le formateur gère-t-il les en-têtes en double ?

Lors de l'analyse, toutes les instances d'en-têtes sont conservées individuellement. Lors de la construction, vous pouvez choisir de garder les doublons séparés (requis pour Set-Cookie) ou de les fusionner en listes séparées par des virgules (valide pour la plupart des autres en-têtes selon la RFC 7230 Section 3.2.2).

Puis-je coller des en-têtes directement depuis les DevTools du navigateur ?

Oui. Le formateur accepte le format brut d'en-têtes affiché dans Chrome DevTools, Firefox Network Inspector et Safari Web Inspector. Il gère également les préfixes > et < de la sortie verbeuse curl -v et les supprime automatiquement.

Quelle est la différence entre le formatage des en-têtes HTTP/1.1 et HTTP/2 ?

HTTP/1.1 utilise des en-têtes en texte clair au format Nom: Valeur avec des fins de ligne CRLF. HTTP/2 utilise un encodage binaire (compression HPACK) et exige que tous les noms d'en-têtes soient en minuscules. De plus, HTTP/2 remplace la ligne de requête (par ex. GET /path HTTP/1.1) par des pseudo-en-têtes comme :method, :path et :scheme. Ce formateur fonctionne avec la représentation texte utilisée dans les logs et les outils de développement, pas avec le format binaire du protocole.

Comment gérer les en-têtes avec des valeurs très longues ?

Certains en-têtes, notamment Set-Cookie et Content-Security-Policy, peuvent avoir des valeurs de plusieurs centaines de caractères. Le formateur affiche les valeurs longues sans troncature pour que vous puissiez voir le contenu complet. Lors de la construction des en-têtes, il n'ajoute pas de pliage de ligne (qui est obsolète en HTTP/1.1) -- chaque en-tête occupe une seule ligne quelle que soit sa longueur.

Puis-je convertir des en-têtes d'un format à un autre en une seule étape ?

Oui. Analysez les en-têtes depuis n'importe quel format d'entrée supporté, puis passez en mode construction pour exporter dans le format souhaité. Cela facilite la conversion de la sortie curl vers JSON, de Postman vers du texte brut, ou du texte brut vers un tableau structuré.

Outils associés

IPparse•Outils de calcul réseau et sous-réseau gratuits

© 2026 IPparse. All tools run locally in your browser.

100% Privacy-First • No Data Collected