Construit de réponse HTTP fictive
Guide
Construit de réponse HTTP fictive
Construire un message de réponse HTTP structuré en secondes. Sélectionner un code d'état, choisir un type de corps, ajouter des en-têtes, et l'outil génère une chaîne prête à coller avec la ligne d'état, les en-têtes et le corps séparés par CRLF — idéal pour les fixtures de test, les mocks d'intégration, les documents d'API et le replay de réponses contre les clients.
Comment utiliser
- Sélectionnez le version HTTP (par défaut HTTP/1.1) et un code d'état dans le sélecteur regroupé — par exemple
200 OK,404 Not Found, ou503 Service Unavailable. - (Facultatif) Surcharger le texte de raison si vous avez besoin d'un texte non standard après le code d'état.
- Choisissez un type de corps (Texte simple, JSON, XML, HTML, Formulaire, ou Aucun) et saisir ou coller le corps.
- Basculer contenu automatique de Content-Type, contenu automatique de Content-Lengthet Date des en-têtes pour correspondre à la manière dont votre serveur répondrait.
- Ajouter tout en-tête supplémentaire — choisir parmi les en-têtes courants (Cache-Control, ETag, Set-Cookie, CORS, en-têtes de limite de vitesse) ou saisir un couple nom/valeur personnalisé.
- Copier la réponse complète, copier uniquement les en-têtes, ou la télécharger sous forme de
.httpfichier pour utilisation dans des clients REST, des fixtures ou des outils de replay.
Caractéristiques
- Sélecteur regroupé des codes d'état – Les codes 1xx à 5xx organisés par classe, chacun avec sa phrase de raison standard.
- Sélecteur du type de corps – Remplit automatiquement le Content-Type correspondant (application/json, text/html, application/xml, application/x-www-form-urlencoded, text/plain) afin que les en-têtes et le payload restent synchronisés.
- Contenu automatique de Content-Length – Compte les octets (et non les caractères) en utilisant l'encodage UTF-8, correspondant à la manière dont les serveurs réels calculent la valeur.
- En-tête IMF-fixdate Date – Génère une date conforme aux normes (par exemple
Sun, 06 Nov 1994 08:49:37 GMT) pour l'instant actuel. - En-têtes de réponse courants – Présents un clic pour Cache-Control, ETag, Expires, Last-Modified, Location, Server, Set-Cookie, Vary, WWW-Authenticate, Access-Control-Allow-Origin, X-RateLimit et X-Powered-By.
- En-têtes personnalisés – Ajouter tout couple nom/valeur, avec une prévisualisation en temps réel de la réponse composée.
- Deux vues de sortie – Réponse complète (ligne d'état + en-têtes + ligne vide + corps) et en-têtes uniquement — copier l'une ou l'autre, ou télécharger la réponse complète sous forme de
response.http. - Lignes correctes selon la norme – Utilise CRLF (
\r\n) entre les lignes, le terminateur de ligne exigé par RFC 9112. - Mises à jour en temps réel – Chaque modification recalculera instantanément la sortie ; aucun bouton d'envoi n'est nécessaire.
- Fonctionne entièrement dans votre navigateur – Aucune donnée ne quitte votre machine et aucun serveur backend n'est impliqué.
Cas d'utilisation courants
- Fixtures pour tests unitaires et d'intégration – Coller la sortie dans un fixture de chaîne pour
requests-mock,nock, MSW, WireMock, ou tout autre enregistreur HTTP. - La documentation API – Afficher une forme exacte de réponse (avec en-têtes) dans les exemples OpenAPI ou dans les documents pour les développeurs.
- Débogage du client – Réproduire une réponse rare d'un serveur (limite de vitesse, contenu partiel, redirection) sans avoir besoin de mettre en place un serveur réel.
- Enseignement de l'HTTP – Visualiser le format en circuit de la réponse : ligne d'état, en-têtes, ligne vide, corps.
- Replay manuel – Pipeler la réponse dans
nc -lou un autre écouteur similaire pour tester la réaction d'un client.
FAQ
-
Quelle est la structure d'un message de réponse HTTP/1.1 ?
Un message de réponse HTTP/1.1 est composé d'une ligne d'état, zéro ou plusieurs champs d'en-tête, une ligne vide, et un corps facultatif. La ligne d'état est la version HTTP, le code d'état à trois chiffres, et une phrase de raison séparés par un seul espace. Chaque ligne est terminée par CRLF (retour chariot + saut de ligne). La ligne vide après le dernier en-tête marque le début du corps. Cette structure est définie dans RFC 9112 (le successeur de RFC 7230).
-
Qu'est-ce que Content-Length mesure exactement, des octets ou des caractères ?
Content-Length est la longueur du corps du message en octets (bytes), et non en caractères. Pour le texte ASCII, les deux valeurs sont identiques, mais pour toute chaîne UTF-8 contenant des caractères non-ASCII, elles divergent — un seul emoji ou une lettre accentuée utilise généralement 2 à 4 octets. Calculer Content-Length à partir du nombre de caractères d'une chaîne est l'un des bugs HTTP les plus courants et causera à la fois le troncage du corps ou le blocage des clients en attente de données manquantes.
-
Quelle est la différence entre une redirection 301 et une redirection 302 ?
Les deux réponses incluent un en-tête Location pointant vers une nouvelle URL, mais les sémantiques sont différentes. Une redirection 301 Moved Permanently indique aux clients et aux moteurs de recherche que la ressource a été déplacée de façon permanente, donc les caches et les réécrivains de liens peuvent remplacer l'URL d'origine. Une redirection 302 Found (originellement 'Moved Temporarily') signale une redirection temporaire — l'URL d'origine devrait être utilisée dans les futures requêtes. Pour les redirections conservant les méthodes modernes, 308 (permanente) et 307 (temporaire) sont généralement préférés à 301 et 302.
-
L'HTTP/2 utilise-t-il encore les lignes d'état et les phrases de raison ?
L'HTTP/2 conserve les codes numériques d'état mais élimine entièrement la phrase de raison. L'état est transmis comme un champ pseudo-header (:status: 200), et le protocole est encodé en binaire plutôt qu'en texte linéaire. Les phrases de raison survivent uniquement dans l'HTTP/1.x et ont toujours été des informations — les clients doivent agir sur le code d'état, pas sur le texte.
-
Pourquoi l'HTTP exige-t-il CRLF au lieu d'un simple saut de ligne ?
L'HTTP hérite de sa convention de terminaison de ligne des protocoles textuels anciens (SMTP, NNTP, FTP) définis dans les années 1980, tous utilisant CRLF (\r\n) comme fin de ligne canonique. Le grammaire de RFC 9112 exige CRLF entre la ligne d'origine, les champs d'en-tête, et la ligne vide précédant le corps. La plupart des serveurs sont tolérants à un saut de ligne pur, mais les analyseurs stricts et les proxies peuvent rejeter les réponses qui omètent le retour chariot.
Installez nos extensions
Ajoutez des outils IO à votre navigateur préféré pour un accès instantané et une recherche plus rapide
恵 Le Tableau de Bord Est Arrivé !
Tableau de Bord est une façon amusante de suivre vos jeux, toutes les données sont stockées dans votre navigateur. D'autres fonctionnalités arrivent bientôt !
Outils essentiels
Tout voir Nouveautés
Tout voirMise à jour: Notre dernier outil a été ajouté le 15 juin 2026
