広告が嫌いですか? 行く広告なし今日 

仮のHTTP応答ビルダー

データ開発者ネットワーキング

広告削除する？

入力

自動処理

HTTP Version

Status Code

Reason Phrase

Optional override for the reason text after the status code.

Body Type

体

Auto-set Content-Type from Body Type

Auto-calculate Content-Length

Include Date header (current time)

カスタムヘッダー

ヘッダーを追加

価値

またはカスタムを追加

ヘッダー名

ヘッダー値

Headers Added

No custom headers added yet. Common headers (Content-Type, Content-Length, Date) are added automatically based on the options above.

出力

クライアント側

広告削除する？

ガイド

仮のHTTP応答ビルダー

Construct a structurally correct HTTP response message in seconds. Pick a status code, choose a body type, add headers, and the tool emits a ready-to-paste response string with the status line, headers, and body separated by CRLF — perfect for test fixtures, integration mocks, API documentation, and replaying responses against clients.

使用方法

を選択します HTTP version (defaults to HTTP/1.1) and a status code from the grouped picker — for example 200 OK, 404 Not Found、または 503 Service Unavailable.
(Optional) Override the reason phrase if you need a non-standard text after the status code.
[ブラウザのchrome]を選択し、 body type (Plain Text, JSON, XML, HTML, Form, or None) and type or paste the body.
トグル auto Content-Type, auto Content-Lengthと、日付 headers to match how your server would respond.
Add any extra headers — pick from common ones (Cache-Control, ETag, Set-Cookie, CORS, rate-limit headers) or type a custom name/value pair.
Copy the full response, copy just the headers, or download it as a .http file for use in REST clients, fixtures, or replay tools.

機能

Grouped status code picker – Common 1xx through 5xx codes organized by class, each with its standard reason phrase.
Body type selector – Auto-fills the matching Content-Type (application/json, text/html, application/xml, application/x-www-form-urlencoded, text/plain) so headers and payload stay in sync.
Auto Content-Length – Counts bytes (not characters) using UTF-8 encoding, matching how real servers compute the value.
IMF-fixdate Date header – Generates a standards-compliant timestamp (e.g. Sun, 06 Nov 1994 08:49:37 GMT) for the current moment.
Common response headers – One-click presets for Cache-Control, ETag, Expires, Last-Modified, Location, Server, Set-Cookie, Vary, WWW-Authenticate, Access-Control-Allow-Origin, X-RateLimit, and X-Powered-By.
– ヘッダー名/値ペアを追加 – Add any name/value pair, with live preview of the assembled response.
Two output views – Full response (status line + headers + blank line + body) and headers-only — copy either, or download the full response as response.http.
Spec-correct line endings – Uses CRLF (\r\n) between lines, the line terminator mandated by RFC 9112.
リアルタイム更新 – Every change recomputes the output instantly; no submit button needed.
ブラウザ内で完全に動作 – No data leaves your machine and no backend is involved.

一般的な使用例

Unit and integration test fixtures – Paste the output into a string fixture for requests-mock, nock, MSW, WireMock, or any HTTP recorder.
API documentation – Show an exact response shape (with headers) in OpenAPI examples or developer docs.
Client debugging – Reproduce a rare server response (rate limited, partial content, redirect) without standing up a real backend.
Teaching HTTP – Visualize the on-the-wire format of a response message: status line, headers, blank line, body.
Manual replay – Pipe the response into nc -l or a similar listener to test how a client reacts.

 よくある質問

What is the structure of an HTTP/1.1 response message?

An HTTP/1.1 response consists of a status line, zero or more header fields, an empty line, and an optional message body. The status line is the HTTP version, the three-digit status code, and a reason phrase separated by single spaces. Every line is terminated by CRLF (carriage return + line feed). The blank CRLF after the last header marks the start of the body. This format is defined in RFC 9112 (the successor to RFC 7230).
What does Content-Length actually measure, bytes or characters?

Content-Length is the length of the message body in octets (bytes), not characters. For ASCII text the two values match, but for any UTF-8 string containing non-ASCII characters they diverge — a single emoji or accented letter typically uses 2–4 bytes. Computing Content-Length from the character count of a string is one of the most common HTTP bugs and will cause clients to either truncate the body or hang waiting for missing bytes.
What is the difference between a 301 and a 302 redirect?

Both responses include a Location header pointing to a new URL, but the semantics are different. A 301 Moved Permanently tells clients and search engines that the resource has been relocated for good, so caches and link rewriters may replace the original URL. A 302 Found (originally 'Moved Temporarily') signals a temporary redirect — the original URL should still be used in future. For modern method-preserving redirects, 308 (permanent) and 307 (temporary) are usually preferred over 301 and 302.
Does HTTP/2 still use status lines and reason phrases?

HTTP/2 keeps the same numeric status codes but drops the textual reason phrase entirely. The status is delivered as a pseudo-header field (:status: 200), and the protocol is framed in binary rather than line-oriented text. Reason phrases survive only in HTTP/1.x and have always been informational — clients are required to act on the status code, not the text.
Why does HTTP require CRLF instead of just a newline?

HTTP inherits its line-termination convention from the older Internet text protocols (SMTP, NNTP, FTP) defined in the 1980s, all of which use CRLF (\r\n) as the canonical end-of-line. The grammar in RFC 9112 requires CRLF between the start-line, header fields, and the empty line preceding the body. Most servers are tolerant of a bare LF, but strict parsers and proxies may reject responses that omit the carriage return.