Keine Werbung mögen? Gehen Werbefrei Heute 

Mock-HTTP-Antwort-Builder

DatenEntwicklerNetzwerk

ANZEIGE Entfernen?

EINGANG

Automatischer Prozess

HTTP-Version

Status-Code

Grundtext

Optional Überschreibung des Grundtextes nach dem Statuscode.

Body-Typ

Körper

Automatische Einstellung des Content-Type aus dem Body-Typ

Automatische Berechnung des Content-Length

Datum-Header einbeziehen (aktuelle Zeit)

Benutzerdefinierte Header

Header hinzufügen

Wert

Oder benutzerdefiniert hinzufügen

Header-Name

Header-Wert

Headers hinzugefügt

Keine benutzerdefinierten Header hinzugefügt. Gemeinsame Header (Content-Type, Content-Length, Date) werden automatisch basierend auf den oben genannten Optionen hinzugefügt.

AUSGABE

Client-Seite

ANZEIGE Entfernen?

Führung

Mock-HTTP-Antwort-Builder

Erstelle eine strukturiert korrekte HTTP-Antwortnachricht in Sekunden. Wählen Sie einen Statuscode, wählen Sie einen Körpertyp, fügen Sie Header hinzu und das Tool gibt eine fertige Antwortzeichenkette mit Statuszeile, Header und Körper aus, getrennt durch CRLF – ideal für Testvorlagen, Integrationstests, API-Dokumentationen und die Wiedergabe von Antworten an Clients.

Nutzung

Wählen Sie den HTTP-Version (Standardmäßig HTTP/1.1) und ein Statuscode aus dem gruppierten Picker – zum Beispiel 200 OK, 404 Not Found, oder 503 Service Unavailable.
(Optional) Überschreibe den Grundtext wenn du einen nicht-standardisierten Text nach dem Statuscode benötigst.
Wählen Sie einen Körpertyp (Text, JSON, XML, HTML, Form oder Kein Körper) und geben Sie den Körper ein.
Umschalten automatische Content-Type, automatische Content-Lengthund Datum Header so einstellen, wie ein Server antworten würde.
Fügen Sie beliebige zusätzliche Header hinzu – wählen Sie aus den gängigen (Cache-Control, ETag, Set-Cookie, CORS, Rate-Limit-Header) oder geben Sie einen benutzerdefinierten Namen/Wert-Paar ein.
Kopieren Sie die vollständige Antwort, kopieren Sie nur die Header oder speichern Sie sie als .http Datei für die Verwendung in REST-Clients, Vorlagen oder Wiedergabewerkzeugen.

Funktionen

Gruppierte Statuscode-Liste – Die gängigen 1xx bis 5xx-Codes sind nach Klassen organisiert, jeweils mit ihrem Standard-Grundtext.
Körpertyp-Selektor – Füllt automatisch den entsprechenden Content-Type (application/json, text/html, application/xml, application/x-www-form-urlencoded, text/plain) aus, damit Header und Payload synchron bleiben.
Automatische Content-Length – Zählt Bytes (nicht Zeichen) mit UTF-8-Encodierung, wie echte Server den Wert berechnen.
IMF-fixdate Datum-Header – Erzeugt einen standardkonformen Zeitstempel (z. B. Sun, 06 Nov 1994 08:49:37 GMT) für den aktuellen Moment.
Gemeinsame Antwort-Header – Einfache Vorlagen für Cache-Control, ETag, Expires, Last-Modified, Location, Server, Set-Cookie, Vary, WWW-Authenticate, Access-Control-Allow-Origin, X-RateLimit und X-Powered-By.
Benutzerdefinierte Kopfzeilen – Fügen Sie beliebige Name/Wert-Paar hinzu, mit Live-Vorschau der zusammengesetzten Antwort.
Zwei Ausgabevorschläge – Vollständige Antwort (Statuszeile + Header + leere Zeile + Körper) und Header-Only – kopieren Sie entweder, oder speichern Sie die vollständige Antwort als response.http.
Spezifikationskorrekte Zeilenumbrüche – Verwendet CRLF (\r\n) zwischen den Zeilen, die durch RFC 9112 vorgeschrieben sind.
Live-Updates – Jede Änderung berechnet sofort die Ausgabe; kein Submit-Button erforderlich.
Laufend im Browser – Keine Daten verlassen Ihr Gerät und kein Backend ist beteiligt.

Häufige Anwendungsfälle

Einheit- und Integrationstestvorlagen – Fügen Sie den Ausgabewert in eine Zeichenkette-Vorlage für requests-mock, nock, MSW, WireMock oder jedes HTTP-Protokoll-Tool ein.
API-Dokumentation – Zeigen Sie eine exakte Antwortform (mit Header) in OpenAPI-Beispielen oder Entwicklungsdocs an.
Client-Debugging – Wiederholen Sie eine seltene Serverantwort (z. B. Rate-Limit, teilweise Inhalt, Redirect), ohne einen echten Backend aufzubauen.
Unterricht über HTTP – Visualisieren Sie die auf dem Netzwerk übertragene Format einer Antwortnachricht: Statuszeile, Header, leere Zeile, Körper.
Manueller Wiedergabe – Leiten Sie die Antwort in nc -l oder ein ähnliches Listener ein, um zu testen, wie ein Client reagiert.

 Häufig gestellte Fragen

Wie sieht die Struktur einer HTTP/1.1-Antwortnachricht aus?

Eine HTTP/1.1-Antwort besteht aus einer Statuszeile, null oder mehr Headerfelder, einer leeren Zeile und einem optionalen Nachrichtenkörper. Die Statuszeile besteht aus der HTTP-Version, dem dreistelligen Statuscode und einem Grundtext, getrennt durch einzelne Leerzeichen. Jede Zeile wird durch CRLF (Zeichenrückgabe + Zeilenumbruch) beendet. Die leere CRLF nach dem letzten Header markiert den Beginn des Körpers. Diese Formatierung ist in RFC 9112 (der Nachfolger von RFC 7230) definiert.
Was misst Content-Length tatsächlich, Bytes oder Zeichen?

Content-Length ist die Länge des Nachrichtenkörpers in Octetten (Bytes), nicht in Zeichen. Für ASCII-Text stimmen beide Werte überein, aber für jede UTF-8-Zeichenkette mit nicht-ASCII-Zeichen divergieren sie – ein einzelner Emoji oder ein akzentuierter Buchstabe verwendet typischerweise 2–4 Bytes. Die Berechnung des Content-Length aus der Zeichenanzahl eines Strings ist eine der häufigsten HTTP-Fehler und führt dazu, dass Clients entweder den Körper abschneiden oder warten, bis fehlende Bytes eingetroffen sind.
Welcher Unterschied besteht zwischen einer 301- und einer 302-Redirect?

Beide Antworten enthalten einen Location-Header, der auf eine neue URL zeigt, aber die Semantik unterscheidet sich. Eine 301 Moved Permanently sagt den Clients und Suchmaschinen, dass die Ressource dauerhaft verschoben wurde, sodass Caches und Link-Überwritern die ursprüngliche URL ersetzen können. Eine 302 Found (ursprünglich „Moved Temporarily“) signalisiert eine temporäre Umleitung – die ursprüngliche URL sollte in Zukunft weiter verwendet werden. Für moderne Methodenbeibehaltungs-Redirects sind 308 (dauerhaft) und 307 (temporär) in der Regel bevorzugt gegenüber 301 und 302.
Verwendet HTTP/2 weiterhin Statuszeilen und Grundtexte?

HTTP/2 behält die numerischen Statuscodes bei, aber entfernt den textuellen Grundtext vollständig. Der Status wird als Pseudokopfzeile (:status: 200) übermittelt, und das Protokoll wird binär statt textbasiert übertragen. Grundtexte überleben nur in HTTP/1.x und waren immer nur informativ – Clients müssen auf den Statuscode reagieren, nicht auf den Text.
Warum benötigt HTTP CRLF anstatt nur einen Zeilenumbruch?

HTTP hat seine Zeilenumbruchkonvention von den älteren Internet-Textprotokollen (SMTP, NNTP, FTP) der 1980er Jahre geerbt, die alle CRLF (\r\n) als Standard-Endzeilen verwenden. Die Grammatik in RFC 9112 erfordert CRLF zwischen der Startzeile, den Headerfeldern und der leeren Zeile vor dem Körper. Die meisten Server sind tolerant gegenüber einem einzigen LF, aber strenge Parser und Proxy-Systeme können Antworten ablehnen, die den Zeichenrückgabewert vermissen.

Möchten Sie werbefrei genießen? Werde noch heute werbefrei



 Erweiterungen installieren

IO-Tools zu Ihrem Lieblingsbrowser hinzufügen für sofortigen Zugriff und schnellere Suche

恵 Die Anzeigetafel ist eingetroffen!

Anzeigetafel ist eine unterhaltsame Möglichkeit, Ihre Spiele zu verfolgen. Alle Daten werden in Ihrem Browser gespeichert. Weitere Funktionen folgen in Kürze!

ANZEIGE Entfernen?