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

仮のHTTP応答ビルダー

データ開発者ネットワーキング
ステータスコード後の理由テキストにオプションで上書きする。

カスタムヘッダー

またはカスタムを追加

追加されたヘッダー

まだカスタムヘッダーは追加されていません。コンテンツタイプ、コンテンツ長、日付などの一般的なヘッダーは、上記のオプションに基づいて自動的に追加されます。

ガイド

モックHTTP応答ビルダー

仮のHTTP応答ビルダー

構造的に正しいHTTP応答メッセージを秒単位で構築します。ステータスコードを選択し、ボディタイプを選び、ヘッダーを追加し、ツールは準備された応答文字列をCRLFで区切って出力し、テストフィクスチャ、統合モック、APIドキュメント、クライアントへの応答再現に最適です。

使用方法

  1. を選択します HTTPバージョン (HTTP/1.1 にデフォルト) および ステータスコード グループ選択器から選択する — たとえば 200 OK, 404 Not Found、 または 503 Service Unavailable.
  2. (オプション) 理由表現を上書きする 理由表現 理由表現を非標準のテキストとして必要に応じて上書きします。
  3. [ブラウザのchrome]を選択し、 ボディタイプ (テキスト、JSON、XML、HTML、フォーム、またはなし) およびボディを入力または貼り付けます。
  4. トグル 自動コンテンツタイプ, 自動コンテンツ長と、 日付 サーバーが応答するようにヘッダーを設定します。
  5. 追加のヘッダーを追加 — 一般的なヘッダー(キャッシュ制御、ETag、Set-Cookie、CORS、レート制限ヘッダー)から選択するか、カスタム名/値ペアを入力します。
  6. 完全な応答をコピー、ヘッダーのみをコピー、または .http ファイルをダウンロードして、RESTクライアント、フィクスチャ、または再現ツールで使用します。

機能

  • グループステータスコード選択器 — 1xxから5xxのコードをクラスごとに整理し、それぞれに標準的な理由表現を提供しています。
  • ボディタイプ選択器 — マッチするコンテンツタイプ(application/json、text/html、application/xml、application/x-www-form-urlencoded、text/plain)を自動で埋め込み、ヘッダーとペイロードを同期させます。
  • 自動コンテンツ長 — UTF-8エンコードを使用してバイト(文字数ではなく)をカウントし、実際のサーバーが値を計算する方法に一致します。
  • IMF-fixdate 日付ヘッダー — 現在の瞬間の標準適合タイムスタンプ(例: Sun, 06 Nov 1994 08:49:37 GMT)を生成します。
  • 一般的な応答ヘッダー — キャッシュ制御、ETag、Expires、Last-Modified、Location、Server、Set-Cookie、Vary、WWW-Authenticate、Access-Control-Allow-Origin、X-RateLimit、およびX-Powered-Byのワンクリックプリセットを提供します。
  • – ヘッダー名/値ペアを追加 — 任意の名前/値ペアを追加し、組み立てられた応答のライブプレビューを表示します。
  • 2つの出力ビュー — 完全応答(ステータス行+ヘッダー+空白行+ボディ)とヘッダーのみ。どちらかをコピー、または完全応答を response.http.
  • 規格適合の行終端 — 行間でCRLF(\r\n)を使用し、RFC 9112で規定された行終端です。
  • リアルタイム更新 — すべての変更が即座に出力が再計算され、提出ボタンは必要ありません。
  • ブラウザ内で完全に動作 — どのデータもあなたのマシンに残り、バックエンドは関与しません。

一般的な使用例

  • ユニットおよび統合テストフィクスチャ — 出力文字列を、 requests-mock, nock、MSW、WireMock、または任意のHTTPレコーダーに貼り付けます。
  • — curl例は、すべてのドキュメントフォーマットです。生成されたコマンドをREADME、Notionページ、Confluenceドキュメントに貼り付けます。どの読者も、言語やスタックに関係なく、すぐに実行できます。 — OpenAPIの例や開発者ドキュメントに、正確な応答の形状(ヘッダー付き)を表示します。
  • クライアントデバッグ — 実サーバーを立ち上げずに、まれなサーバー応答(レート制限、部分コンテンツ、リダイレクト)を再現できます。
  • HTTPの教育 — 応答メッセージのオンザワイヤー形式(ステータス行、ヘッダー、空白行、ボディ)を可視化します。
  • 手動再現 — 応答を nc -l または類似のリスナーにパイプし、クライアントがどのように反応するかをテストします。

よくある質問

  1. HTTP/1.1応答メッセージの構造は?

    HTTP/1.1応答は、ステータス行、ゼロまたは複数のヘッダー、空白行、およびオプションのメッセージボディから構成されています。ステータス行は、HTTPバージョン、3桁のステータスコード、およびスペースで区切られた理由表現です。すべての行はCRLF(キャリッジリターン+ラインフィード)で終了されます。最後のヘッダーの後にある空白CRLFはボディの開始を示します。この形式はRFC 9112(RFC 7230の継承)で定義されています。

  2. コンテンツ長は、バイトか文字を測定しますか?

    コンテンツ長はメッセージボディのオクテット(バイト)長であり、文字ではありません。ASCIIテキストでは両方の値が一致しますが、UTF-8エンコードで非ASCII文字を含む場合、値は異なる——1つのエモジーやアクセント文字は通常2~4バイトを使用します。コンテンツ長を文字数から計算することは、HTTPの最も一般的なバグの一つであり、クライアントはボディを切り詰めたり、欠落したバイトを待つためにブロックされます。

  3. 301と302のリダイレクトの違いは?

    両方の応答には新しいURLを指すLocationヘッダーが含まれていますが、意味は異なります。301 Moved Permanentlyは、クライアントおよび検索エンジンにリソースが永久に移動したことを示し、キャッシュやリンクリワイタが元のURLを置き換える可能性があります。302 Found(元々は'Moved Temporarily')は一時的なリダイレクトを示し、将来は元のURLを使用すべきです。現代のメソッドを保持するリダイレクトでは、308(永久)および307(一時)が301および302よりも好まれます。

  4. HTTP/2はステータス行と理由表現を使用していますか?

    HTTP/2は数値ステータスコードを維持していますが、テキスト理由表現を完全に削除しています。ステータスは偽ヘッダー(:status: 200)として提供され、プロトコルはテキストではなくバイナリでフレーム化されています。理由表現はHTTP/1.xにのみ存在し、常に情報的なものであり、クライアントはステータスコードに反応しなければなりません。

  5. HTTPはCRLFを使用する理由は?

    HTTPは1980年代に定義された古いインターネットテキストプロトコル(SMTP、NNTP、FTP)から継承した行終了規則を持ち、すべてがCRLF(\r\n)を標準的な終了行として使用しています。RFC 9112の文法では、開始行、ヘッダー項目、およびボディ前の空行の間でCRLFが必須です。多くのサーバーはLFだけを許容していますが、厳密なパーサーおよびプロキシは、キャリッジリターンを省略した応答を拒否する可能性があります。

広告なしで楽しみたいですか? 今すぐ広告なしで

拡張機能をインストールする

お気に入りのブラウザにIOツールを追加して、すぐにアクセスし、検索を高速化します。

に追加 Chrome拡張機能 に追加 エッジ拡張 に追加 Firefox 拡張機能 に追加 Opera 拡張機能

スコアボードが到着しました!

スコアボード ゲームを追跡する楽しい方法です。すべてのデータはブラウザに保存されます。さらに多くの機能がまもなく登場します!

ニュースコーナー 技術ハイライト付き

参加する

価値ある無料ツールの提供を継続するためにご協力ください

コーヒーを買って