# リクエスト設定 (/ja/docs/requests/settings)

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

<Shot id="requests-http-settings" alt="リクエストの設定タブ：生データモード、注記付きで自動のHTTPバージョン、TLS証明書を検証、最大リダイレクト数10のリダイレクトに従う、Cookie、レスポンスを展開、タイムアウト60 s" />

## 設定タブ [#the-settings-tab]

| 設定 | デフォルト | 内容 |
| --- | --- | --- |
| <strong>生データモード</strong> | オフ | <strong>ヘッダー</strong>タブのヘッダーだけを、何も追加せずにそのまま送信します。 |
| <strong>HTTPバージョン</strong> | <strong>自動</strong> | <strong>自動</strong>、<strong>HTTP/1.1</strong>、<strong>HTTP/2</strong>、<strong>HTTP/3</strong>。 |
| <strong>TLS証明書を検証</strong> | オン | `https://`のアドレスで、サーバの証明書を検証します。 |
| <strong>リダイレクトに従う</strong> | オン | 3xxのレスポンスに、<strong>最大リダイレクト数</strong>まで従います。 |
| <strong>最大リダイレクト数</strong> | 10 | 1〜50。 |
| <strong>Cookieを送信・保存</strong> | オン | ウインドウのジャーにあるそのアドレスのCookieを送信し、レスポンスが設定したCookieを保持します。 |
| <strong>レスポンスを展開</strong> | オン | 圧縮されたレスポンスを要求し、デコードします。 |
| <strong>タイムアウト</strong> | 60 s | やり取り全体にかけてよい時間。1秒から1時間まで、5秒刻み。 |

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

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

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

## HTTPバージョン [#http-version]

| 選択肢 | Echolotが送信するもの |
| --- | --- |
| <strong>自動</strong> | サーバが対応していればHTTP/2、そうでなければHTTP/1.1。サーバがHTTP/3を提供すると（`Alt-Svc`ヘッダーで）、以降のリクエストはHTTP/3を使い、接続できなければTCPにフォールバックします。 |
| <strong>HTTP/1.1</strong> | HTTP/1.1のみ。 |
| <strong>HTTP/2</strong> | HTTP/2のみ：TLS上、またはプレーンな`http://`上で事前知識を使う方式（h2c）。 |
| <strong>HTTP/3</strong> | QUIC上のHTTP/3のみ。 |

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

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

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

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

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

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

## リダイレクト [#redirects]

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

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

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

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

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

## Cookie [#cookies]

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

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

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

## レスポンスを展開 [#decompress-responses]

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

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

## TLS証明書を検証 [#verify-tls-certificates]

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

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

## タイムアウト [#timeout]

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

## 生データモード [#raw-mode]

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

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

## 再試行 [#retries]

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

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

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

## プロキシ [#proxies]

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

| プロキシ | 意味 |
| --- | --- |
| <strong>システム設定</strong> | <strong>システム設定 › ネットワーク</strong>のHTTP、HTTPS、SOCKSプロキシと、その例外。自動プロキシ構成（PAC）は使いません。 |
| <strong>なし</strong> | すべてのリクエストが直接接続します。 |
| <strong>手動</strong> | HTTP、HTTPS（プロキシへはTLS）、SOCKS5のプロキシ。`http://proxy:3128`や`socks5://host:1080`のように指定し、任意でユーザー名とパスワード（キーチェーンに保存）、<strong>直接接続するホスト</strong>で直接接続するホスト（`localhost, *.internal`）を指定します。 |

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

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

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

## 証明書 [#certificates]

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

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

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

<Edition only="appstore">
  App Storeエディションが読み込めるのは、自分で選んだファイルだけです。ここで選んだCAファイル、クライアント証明書、鍵は、以降の送信でも読み込めるままです。
  チームメイトが作成した、ワークスペースの外のファイルを指すルールでは、アプリにそれらのファイルを一度渡す必要があります。送信は止まり、レスポンスペインに<strong>アクセスを許可…</strong>が表示されます。
</Edition>

## アプリ全体の設定 [#app-wide-settings]

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