リクエスト設定

設定タブには、リクエストの送り方に関する設定があります。どのHTTPバージョンを使うか、リダイレクトに従うか、Cookieを保持するか、証明書を検証するか、どのくらい時間をかけてよいかです。 プロキシと証明書は、このページの後半で説明するとおり、ワークスペース全体またはアプリ全体に設定します。

設定タブCopy Anchor Link

保存されるのは、変更した設定だけで、リクエストのファイルに保存されます。設定のどれかがデフォルトと異なると、タブにドットが表示され、生データモードがオンの間は設定（生データ）と表示されます。 デフォルトに戻すで、すべての設定が元に戻ります。

リクエストファイルでは、設定は次のようになります：

[settings]
http-version = "http2"
follow-redirects = false
timeout = 10.0

HTTPバージョンCopy Anchor Link

HTTP/3には制限があります：

• macOS 27以降が必要です。それより古いMacでは、タブにそう表示され、HTTP/3に設定したリクエストは送信できません。自動はHTTP/2とHTTP/1.1のままです。
• https://のアドレスのみ。
• プロキシ（システムのプロキシも含む）、カスタムCAファイル、クライアント証明書は使えません。HTTP/3に設定したリクエストがこれらのいずれかを必要とすると、理由とともに拒否されます。自動では、そのようなリクエストはTCPのままです。
• 生データモードはHTTP/3では使えません。

自動で、レスポンスがHTTP/3を提供すると、その詳細カードにHTTP/3を提供と表示されます。次のリクエストのQUIC接続が失敗すると、EcholotはTCPで送信し直し、提供情報を破棄して、 詳細カードにその理由を表示します。二重に送信されることはありません。

自動でバージョンを切り替えるケースがほかに2つあります：

• NTLMにはHTTP/1.1が必要です。自動では、NTLMのリクエストはHTTP/1.1で送信され、HTTP/2またはHTTP/3では拒否されます。
• サーバがHTTP/2のリクエストをHTTP_1_1_REQUIREDでリセットした場合、Echolotはそれ以降、そのサーバとHTTP/1.1で通信します。繰り返しても安全なリクエストは、すぐにHTTP/1.1で再送信されます。 それ以外のリクエストは、その旨のエラーで止まり、もう一度送信するとHTTP/1.1で送られます。

レスポンスの詳細カードには、TLSのバージョンの隣に、使われたバージョンが表示されます。

リダイレクトCopy Anchor Link

リダイレクトに従うがオンのとき、Echolotはhttp://とhttps://のアドレスへの301、302、303、307、308のレスポンスに従います：

• 303は、ボディなしのGETになります（HEADはHEADのままです）。
• 301と302は、ブラウザと同じように、POSTをGETに変えます。
• 307と308は、メソッドとボディを保持します。

すべてのホップが記録されます。詳細カードには3回のリダイレクト（またはその回数）と表示され、クリックすると、各ホップのステータス、メソッド、アドレス、時間と、最終的なアドレスが分かります。 AlpenglowのEcho › Follow redirectsで試せます。

別のオリジンへのリダイレクトでは、認証情報が外されます：AuthorizationとCookieヘッダー、APIキーのヘッダー、シークレットを含むヘッダー、署名（Digest、AWS、Hawk、EdgeGrid、NTLM）、クライアント証明書です。 認証情報は送信元のオリジンにとどまるを参照してください。

リダイレクトに従うがオフのとき、3xxのレスポンスがそのままレスポンスになります。

CookieCopy Anchor Link

各ウインドウにはCookieジャーがあります。Cookieを送信・保存がオンのとき、リクエストはジャーにあるアドレスに一致するCookieを送信し、レスポンスが設定したCookieはジャーに入ります。 Cookieを送信も保持もしないリクエストでは、オフにします。

レスポンスのCookieタブには、リクエストと一緒に送信されたもの、レスポンスで設定されたもの、このウインドウに保存されているものが表示されます。 個別のボタンでCookieを1つ削除でき、すべて消去ですべて削除できます。レスポンスを参照してください。

ジャーはブラウザのルールに従います。レスポンスは、.comや.co.ukのようなパブリックサフィックス全体に対するCookieを設定できません。 AlpenglowのEcho › Set a cookieを試し、続いてdemo.echolot.devへのほかのリクエストを試してみてください。

レスポンスを展開Copy Anchor Link

レスポンスを展開がオンのとき、EcholotはAccept-Encoding: gzip, deflate, br, zstdを送信し（そのヘッダーを自分で設定していない場合）、gzip、deflate、Brotli、Zstandardのレスポンスをデコードします。 ボディタブにはデコード後のボディが表示されます。届いたままのバイトは通信タブに残り、ボディの保存メニューにはエンコードされたボディを保存…があります。 詳細カードには、たとえばbr, 12 KB → 48 KBと表示されます。

サーバが圧縮したままのレスポンスを見たいとき、またはAccept-Encodingヘッダーを送信したくないときは、オフにします。

TLS証明書を検証Copy Anchor Link

Macが信頼しない証明書を持つサーバに対してテストしていて、そのCAを追加できない場合を除き、オンのままにしておいてください。オフにすると、詳細カードにオレンジの開いた鍵が表示され、 ポップオーバーには証明書の検証はオフですと表示されます。

プライベートCAには、そのホストに対してCAを信頼する方法のほうが適しています。証明書を参照してください。

タイムアウトCopy Anchor Link

タイムアウトは、接続から最後のバイトまで、やり取り全体にかけてよい時間です。時間切れになると、リクエストはリクエストがタイムアウトしましたで止まり、接続は閉じられます。

生データモードCopy Anchor Link

生データモードは、不正な形式のものも含め、書いたとおりにリクエストをバイト単位で送信して、サーバの扱いをテストするためのものです。 Echolotは、すべてのリクエストに追加するヘッダー（Host、User-Agent、Accept、Accept-Encoding、Cookie、Content-Length、フレーミング）を省き、リクエストの形式が正しいかどうかも確認しません。 ヘッダータブの自動生成の下には、生データモード：Echolotはヘッダーを追加せず、上記のヘッダーのみを送信します。と表示されます。

自分のヘッダーだけを送信するリクエストにするには、認証も認証なしにし、ボディに必要ならContent-Typeも自分で書きます。生データモードはHTTP/1.1で書き出すため、HTTP/3では使えません。

再試行Copy Anchor Link

Echolotは接続を開いたままにして再利用するので、DNS、接続、TLSの時間が省けます。再利用したときは、詳細カードに再利用した接続と表示されます。 サーバが、開いたままの接続を、ちょうどリクエストが送り出されるときに閉じてしまうことがあります。その場合：

• 繰り返しても安全なリクエストは、新しい接続で再送信されます：GET、HEAD、OPTIONS、TRACE、PUT、DELETE、またはIdempotency-Keyヘッダーを持つすべてのリクエスト。詳細カードに、再送信されたことが表示されます。
• それ以外のリクエスト（たとえばIdempotency-KeyのないPOST）は、サーバがすでに処理した可能性があるので、再送信されません。 レスポンスが届く前に接続が閉じました。サーバがリクエストを適用した可能性がありますで止まります。

Echolotがそれ以外の場合に再試行することはありません。

プロキシCopy Anchor Link

リクエストは、デフォルトでは設定 › ネットワークで選んだプロキシを経由します：

ワークスペースに独自のプロキシを設定できます。これはチームメイトやコマンドラインツールにもワークスペースとともに引き継がれます：

1. サイドバー下部のワークスペーススイッチャからワークスペース設定…を開きます。
2. プロキシタブを選び、アプリのプロキシ設定を使用をオフにします。
3. システム設定、環境変数（HTTPS_PROXY…）（HTTPS_PROXY、HTTP_PROXY、NO_PROXYを読み取ります）、なし、手動のいずれかを選びます。
4. 手動では、プロキシ（{{proxy}}のように変数が使えます）、ユーザー名、パスワード、直接接続するホストを入力します。 パスワードはシークレット変数{{proxy_password}}として書いてください。ワークスペースのファイルにシークレットは残りません。パスワードをそのまま入力すると、キーチェーンに移動が表示されます。

HTTP/3は、プロキシを経由しません。ワークスペースを参照してください。

証明書Copy Anchor Link

プライベートな認証局を使うホストや、クライアント証明書（相互TLS）を求めるホストには、ワークスペースにルールを追加します：

1. ワークスペース設定…を開いて、証明書タブを選びます。
2. ホストを追加をクリックして、ホストを入力します。たとえばapi.example.com、すべてのサブドメインなら*.internalです。
3. 信頼するCAの横の選択…をクリックして、PEMファイルを1つ以上選びます。システムのものに加えて信頼されます。
4. クライアント証明書は、クライアント証明書の横でファイルを選びます：PEMファイル、または.p12（.pfx）です。ファイルに鍵が含まれていないPEM証明書では、秘密鍵のファイルも選びます。
5. 鍵または.p12にパスフレーズがある場合は、パスフレーズにシークレット変数として書きます。たとえば{{p12_passphrase}}です。

ホストに最初に一致したルールが使われます。ワークスペース内のファイルは、ワークスペースからの相対パスとして保存されるため、ルールはワークスペースを持つ全員に有効です。 各ルールの証明書はそのホストにだけ使われます。別のホストへのリダイレクトで、最初のホストのクライアント証明書が提示されることはありません。

アプリ全体の設定Copy Anchor Link

プロキシは、アプリ全体のデフォルトがある唯一のリクエスト設定です（設定 › ネットワーク）。ほかの設定は、リクエストごとに上の表のデフォルトから始まり、リクエストのファイルに変更内容が保存されます。 多くのリクエストの設定をまとめて変更するには、サイドバーでそれらを選択して、ヘッダー、パラメータ、認証にはN件のリクエストを編集…を使うか、ファイルを編集します。