5. Request Header Fields (リクエストヘッダーフィールド)
クライアントは、リクエストコンテキストに関する詳細情報を提供したり、ターゲットリソースの状態に基づいてリクエストを条件付きにしたり、レスポンスの優先形式を提案したり、認証資格情報を提供したり、予想されるリクエスト処理を変更したりするために、リクエストヘッダーフィールドを送信します。これらのフィールドは、プログラミング言語のメソッド呼び出しのパラメータと同様に、リクエスト修飾子として機能します。
5.1. Controls (制御)
制御は、リクエストの特定の処理を指示するリクエストヘッダーフィールドです。
5.1.1. Expect (期待)
リクエストの Expect ヘッダーフィールドは、このリクエストを適切に処理するためにサーバーがサポートする必要がある特定の動作のセット（期待）を示します。本仕様で定義されている唯一のこのような期待は 100-continue です。
Expect = "100-continue"
Expect フィールド値は大文字小文字を区別しません。
100-continue 以外の Expect フィールド値を受信したサーバーは、予期しない期待を満たすことができないことを示すために、417 (Expectation Failed) ステータスコードで応答してもよい (MAY) です。
100-continue 期待は、クライアントがこのリクエストで（おそらく大きな）メッセージボディを送信しようとしており、メソッド、ターゲット URI、およびヘッダーフィールドが即座の成功、リダイレクト、またはエラーレスポンスを引き起こすのに十分でない場合に 100 (Continue) 暫定レスポンスを受信したいことを受信者に通知します。これにより、クライアントは実際に送信する前にメッセージボディを送信する価値があることを示す指示を待つことができ、メッセージボディが大きい場合や、クライアントがエラーが発生する可能性が高いと予想する場合（たとえば、以前に検証された認証資格情報なしで、初めて状態変更メソッドを送信する場合）に効率を向上させることができます。
例：
Expect: 100-continue
100-continue 期待を送信するクライアントは、特定の時間待つ必要はありません。そのようなクライアントは、まだレスポンスを受信していない場合でも、メッセージボディの送信を続行してもよい (MAY) です。さらに、100 (Continue) レスポンスは HTTP/1.0 仲介者を通じて送信できないため、そのようなクライアントはメッセージボディを送信する前に無期限に待つべきではありません (SHOULD NOT)。
クライアントの要件：
- クライアントは、メッセージボディを含まないリクエストで 100-continue 期待を生成してはなりません (MUST NOT)。
サーバーの要件：
- HTTP/1.0 リクエストで 100-continue 期待を受信したサーバーは、その期待を無視しなければなりません (MUST)。
- サーバーは、対応するリクエストのメッセージボディの一部またはすべてをすでに受信している場合、またはフレーミングがメッセージボディがないことを示している場合、100 (Continue) レスポンスの送信を省略してもよい (MAY) です。
- 100 (Continue) レスポンスを送信するサーバーは、メッセージボディが受信され処理されたら、接続が早期に閉じられない限り、最終的に最終ステータスコードを送信しなければなりません (MUST)。
- メッセージボディ全体を読み取る前に最終ステータスコードで応答するサーバーは、そのレスポンスで接続を閉じるつもりか、リクエストメッセージの読み取りと破棄を続けるつもりかを示すべきです (SHOULD)（[RFC7230] の Section 6.6 を参照）。
5.1.2. Max-Forwards (最大転送回数)
Max-Forwards ヘッダーフィールドは、TRACE (Section 4.3.8) および OPTIONS (Section 4.3.7) リクエストメソッドで、リクエストがプロキシによって転送される回数を制限するメカニズムを提供します。これは、クライアントがチェーンの途中で失敗またはループしているように見えるリクエストをトレースしようとしているときに便利です。
Max-Forwards = 1*DIGIT
Max-Forwards 値は、このリクエストメッセージが転送できる残りの回数を示す十進整数です。
Max-Forwards ヘッダーフィールドを含む TRACE または OPTIONS リクエストを受信した各仲介者は、リクエストを転送する前にその値をチェックして更新しなければなりません (MUST)。受信した値がゼロ (0) の場合、仲介者はリクエストを転送してはなりません (MUST NOT)。代わりに、仲介者は最終受信者として応答しなければなりません (MUST)。受信した Max-Forwards 値がゼロより大きい場合、仲介者は転送されたメッセージに更新された Max-Forwards フィールドを生成しなければなりません (MUST)。フィールド値は、a) 受信した値を 1 減らしたもの、または b) 受信者がサポートする最大値のいずれか小さい方です。
受信者は、他のリクエストメソッドで受信した Max-Forwards ヘッダーフィールドを無視してもよい (MAY) です。
例：
Max-Forwards: 10
5.2. Conditionals (条件)
HTTP 条件付きリクエストヘッダーフィールド [RFC7232] により、クライアントはターゲットリソースの状態に前提条件を設定できるため、前提条件が false と評価された場合、メソッドセマンティクスに対応するアクションは適用されません。本仕様で定義されている各前提条件は、ターゲットリソースの以前の表現から取得した一連のバリデーターと、選択された表現の現在のバリデーターの状態との比較で構成されます（[RFC7232] の Section 7.2）。したがって、これらの前提条件は、クライアントが知っている特定の状態以降、ターゲットリソースの状態が変化したかどうかを評価します。このような評価の効果は、[RFC7232] の Section 5 で定義されているように、メソッドセマンティクスと条件の選択に依存します。
5.3. Content Negotiation (コンテンツネゴシエーション)
以下のリクエストヘッダーフィールドは、Section 3.4.1 で定義されているように、レスポンスコンテンツのプロアクティブネゴシエーションに参加するためにユーザーエージェントによって送信できます。これらのフィールドで送信される設定は、ターゲットリソースの表現、エラーまたは処理ステータスの表現、さらにはプロトコル内に表示される可能性のある雑多なテキスト文字列を含む、レスポンス内の任意のコンテンツに適用されます。
5.3.1. Quality Values (品質値)
プロアクティブネゴシエーションの多くのリクエストヘッダーフィールドは、"q"（大文字小文字を区別しない）という名前の共通パラメータを使用して、その関連するコンテンツの種類に対する設定に相対的な「重み」を割り当てます。この重みは「品質値」（または "qvalue"）と呼ばれます。同じパラメータ名がサーバー構成内でリソースに選択できるさまざまな表現の品質に重みを割り当てるためによく使用されるためです。
重みは 0 から 1 の範囲の実数に正規化されます。0.001 が最も優先度が低く、1 が最も優先度が高くなります。値 0 は「受け入れられない」を意味します。"q" パラメータが存在しない場合、デフォルトの重みは 1 です。
weight = OWS ";" OWS "q=" qvalue
qvalue = ( "0" [ "." 0*3DIGIT ] )
/ ( "1" [ "." 0*3("0") ] )
qvalue の送信者は、小数点以下 3 桁を超える数字を生成してはなりません (MUST NOT)。これらの値のユーザー設定は、同じ方法で制限されるべきです。
例：
Accept: text/html;q=1, application/json;q=0.8
Accept-Language: en-US;q=0.9, fr;q=0.7
5.3.2. Accept (受け入れ)
Accept ヘッダーフィールドは、ユーザーエージェントが受け入れ可能なレスポンスメディアタイプを指定するために使用できます。Accept ヘッダーフィールドは、インライン画像のリクエストの場合のように、リクエストが特に希望するタイプの小さなセットに限定されていることを示すために使用できます。
Accept = #( media-range [ accept-params ] )
media-range = ( "*/*"
/ ( type "/" "*" )
/ ( type "/" subtype )
) *( OWS ";" OWS parameter )
accept-params = weight *( accept-ext )
accept-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ]
アスタリスク "" 文字は、メディアタイプを範囲にグループ化するために使用され、"/" はすべてのメディアタイプを示し、"type/" はそのタイプのすべてのサブタイプを示します。media-range には、その範囲に適用可能なメディアタイプパラメータを含めることができます。
各 media-range の後には、ゼロ個以上の適用可能なメディアタイプパラメータ（例：charset）、相対的な重みを示すためのオプションの "q" パラメータ（Section 5.3.1）、次にゼロ個以上の拡張パラメータが続くことがあります。拡張 (accept-ext) が存在する場合は "q" パラメータが必要です。これにより、それらがメディアタイプパラメータと誤認されることがありません。
例
Accept: audio/*; q=0.2, audio/basic
は、「私は audio/basic を好みますが、品質を 80% 割り引いた後で最も利用可能な場合は、任意のオーディオタイプを送ってください」と解釈されます。
より精巧な例は
Accept: text/plain; q=0.5, text/html,
text/x-dvi; q=0.8, text/x-c
口頭で、これは「text/html と text/x-c は同等に優先されるメディアタイプですが、それらが存在しない場合は、text/x-dvi 表現を送信し、それも存在しない場合は text/plain 表現を送信してください」と解釈されます。
メディア範囲は、より具体的なメディア範囲または特定のメディアタイプによって上書きできます。複数のメディア範囲が特定のタイプに適用される場合、最も具体的な参照が優先されます。例えば、
Accept: text/*, text/plain, text/plain;format=flowed, */*
次の優先順位があります：
- text/plain;format=flowed
- text/plain
- text/*
- /
特定のタイプに関連付けられたメディアタイプ品質係数は、そのタイプに一致する最も優先度の高いメディア範囲を見つけることによって決定されます。例えば、
Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
text/html;level=2;q=0.4, */*;q=0.5
次の値が関連付けられます：
| メディアタイプ | 品質値 |
|---|---|
| text/html;level=1 | 1 |
| text/html | 0.7 |
| text/plain | 0.3 |
| image/jpeg | 0.5 |
| text/html;level=2 | 0.4 |
| text/html;level=3 | 0.7 |
注意： ユーザーエージェントには、特定のメディア範囲のデフォルトの品質値セットが提供される場合があります。ただし、ユーザーエージェントが他のレンダリングエージェントと対話できない閉じたシステムでない限り、このデフォルトセットはユーザーが設定できるようにすべきです。
5.3.3. Accept-Charset (文字セットの受け入れ)
Accept-Charset ヘッダーフィールドは、テキストレスポンスコンテンツで受け入れ可能な文字セットを示すためにユーザーエージェントによって送信できます。このフィールドにより、より包括的または特殊な目的の文字セットを理解できるユーザーエージェントは、それらの文字セットで情報を表現できるオリジンサーバーにその能力を通知できます。
Accept-Charset = 1#( ( charset / "*" ) [ weight ] )
文字セット名は Section 3.1.1.2 で定義されています。ユーザーエージェントは、Section 5.3.1 で定義されているように、ユーザーのその文字セットに対する相対的な設定を示すために、各文字セットに品質値を関連付けてもよい (MAY) です。例は次のとおりです：
Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
特殊値 "" が Accept-Charset フィールドに存在する場合、Accept-Charset フィールドの他の場所で言及されていないすべての文字セットに一致します。Accept-Charset フィールドに "" が存在しない場合、フィールドで明示的に言及されていない文字セットは、クライアントにとって「受け入れられない」と見なされます。
Accept-Charset ヘッダーフィールドのないリクエストは、ユーザーエージェントがレスポンスで任意の文字セットを受け入れることを意味します。ほとんどの汎用ユーザーエージェントは、特に設定されていない限り Accept-Charset を送信しません。サポートされている文字セットの詳細なリストにより、サーバーは珍しい（ローカライズされた）設定によって個人を識別しやすくなるためです。
リクエストに Accept-Charset ヘッダーフィールドが存在し、レスポンスの利用可能な表現のいずれも受け入れ可能としてリストされている文字セットを持たない場合、オリジンサーバーは、406 (Not Acceptable) レスポンスを送信してヘッダーフィールドを尊重するか、リソースをコンテンツネゴシエーションの対象ではないとして扱うことでヘッダーフィールドを無視できます。
5.3.4. Accept-Encoding (エンコーディングの受け入れ)
Accept-Encoding ヘッダーフィールドは、レスポンスで受け入れ可能なレスポンスコンテンツコーディング (Section 3.1.2.1) を示すためにユーザーエージェントによって使用できます。"identity" トークンは、エンコーディングが優先されない場合に通信するために、"エンコーディングなし" の同義語として使用されます。
Accept-Encoding = #( codings [ weight ] )
codings = content-coding / "identity" / "*"
各 codings 値には、Section 5.3.1 で定義されているように、そのエンコーディングに対する設定を表す関連する品質値（重み）を与えることができます (MAY)。Accept-Encoding フィールドのアスタリスク "*" シンボルは、ヘッダーフィールドに明示的にリストされていない利用可能なコンテンツコーディングに一致します。
例：
Accept-Encoding: compress, gzip
Accept-Encoding:
Accept-Encoding: *
Accept-Encoding: compress;q=0.5, gzip;q=1.0
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
Accept-Encoding ヘッダーフィールドのないリクエストは、ユーザーエージェントがコンテンツコーディングに関して設定を持たないことを意味します。これにより、サーバーはレスポンスで任意のコンテンツコーディングを使用できますが、ユーザーエージェントがすべてのエンコーディングを正しく処理できることを意味するわけではありません。
サーバーは、次の規則を使用して、特定の表現のコンテンツコーディングが受け入れ可能かどうかをテストします：
-
リクエストに
Accept-Encodingフィールドがない場合、ユーザーエージェントは任意のコンテンツコーディングを受け入れ可能と見なします。 -
表現にコンテンツコーディングがない場合、
Accept-Encodingフィールドが "identity;q=0" または "*;q=0" を示し、"identity" のより具体的なエントリがない場合を除き、デフォルトで受け入れ可能です。 -
表現のコンテンツコーディングが
Accept-Encodingフィールドにリストされているコンテンツコーディングの 1 つである場合、qvalue が 0 でない限り受け入れ可能です。（Section 5.3.1 で定義されているように、qvalue が 0 は「受け入れられない」を意味します。） -
複数のコンテンツコーディングが受け入れ可能な場合、最も高い非ゼロ qvalue を持つ受け入れ可能なコンテンツコーディングが優先されます。
空の組み合わせフィールド値を持つ Accept-Encoding ヘッダーフィールドは、ユーザーエージェントがレスポンスでコンテンツコーディングを望まないことを意味します。リクエストに Accept-Encoding ヘッダーフィールドが存在し、レスポンスの利用可能な表現のいずれも受け入れ可能としてリストされているコンテンツコーディングを持たない場合、オリジンサーバーはコンテンツコーディングなしでレスポンスを送信すべきです (SHOULD)。
注意： ほとんどの HTTP/1.0 アプリケーションは、コンテンツコーディングに関連付けられた qvalue を認識または遵守しません。これは、qvalue が機能しない可能性があり、x-gzip または x-compress では許可されていないことを意味します。
5.3.5. Accept-Language (言語の受け入れ)
Accept-Language ヘッダーフィールドは、レスポンスで優先される自然言語のセットを示すためにユーザーエージェントによって使用できます。言語タグは Section 3.1.3.1 で定義されています。
Accept-Language = 1#( language-range [ weight ] )
language-range =
<language-range, see [RFC4647], Section 2.1>
各 language-range には、Section 5.3.1 で定義されているように、その範囲で指定された言語に対するユーザーの設定の推定を表す関連する品質値を与えることができます。例えば、
Accept-Language: da, en-gb;q=0.8, en;q=0.7
は「私はデンマーク語を好みますが、イギリス英語や他のタイプの英語も受け入れます」という意味になります。
Accept-Language ヘッダーフィールドのないリクエストは、ユーザーエージェントがレスポンスで任意の言語を受け入れることを意味します。リクエストにヘッダーフィールドが存在し、レスポンスの利用可能な表現のいずれも一致する言語タグを持たない場合、オリジンサーバーは、リソースをコンテンツネゴシエーションの対象ではないとして扱うことでヘッダーフィールドを無視するか、406 (Not Acceptable) レスポンスを送信してヘッダーフィールドを尊重できます。ただし、後者は推奨されません。そうすることで、ユーザーが使用できる可能性のあるコンテンツ（たとえば、翻訳ソフトウェアを使用する場合）へのアクセスを妨げる可能性があるためです。
一部の受信者は、言語タグがリストされている順序を優先度の降順を示すものとして扱うことに注意してください。特に、同等の品質値が割り当てられているタグ（値なしは q=1 と同じ）の場合です。ただし、この動作に依存することはできません。一貫性を保ち、相互運用性を最大化するために、多くのユーザーエージェントは各言語タグに一意の品質値を割り当てます。
言語優先度リストに関する追加の議論は、[RFC4647] の Section 2.3 にあります。
5.4. Authentication Credentials (認証資格情報)
HTTP 認証 [RFC7235] で定義されているように、2 つのヘッダーフィールドが認証資格情報を運ぶために使用されます。さまざまなカスタムユーザー認証メカニズムは、[RFC6265] で定義されているように、この目的で Cookie ヘッダーフィールドを使用することに注意してください。
5.4.1. Authorization (認証)
Authorization ヘッダーフィールドにより、ユーザーエージェントはオリジンサーバーで自己認証できます。通常、401 (Unauthorized) レスポンスを受信した後ですが、必ずしもそうとは限りません。その値は、リクエストされているリソースの領域のユーザーエージェントの認証情報を含む資格情報で構成されます。
Authorization = credentials
リクエストが認証され、領域が指定されている場合、同じ資格情報がこの領域内の他のすべてのリクエストに対して有効であると推定されます（認証スキーム自体が、チャレンジ値に応じて変化する資格情報や同期クロックの使用など、他の方法を要求しない限り）。
リクエストを転送するプロキシは、そのリクエスト内の Authorization フィールドを変更してはなりません (MUST NOT)。詳細については、[RFC7235] の Section 3.2 を参照してください。
ユーザーエージェントがパスワードを含む資格情報を送信するには、オリジンサーバーへの接続が安全であることを知っている必要があります。関連するセキュリティの考慮事項については、Section 9.4 を参照してください。
5.4.2. Proxy-Authorization (プロキシ認証)
Proxy-Authorization ヘッダーフィールドにより、クライアントは認証を要求するプロキシに対して自分自身（またはそのユーザー）を識別できます。その値は、プロキシおよび/またはリクエストされているリソースの領域に対するクライアントの認証情報を含む資格情報で構成されます。
Proxy-Authorization = credentials
Authorization とは異なり、Proxy-Authorization ヘッダーフィールドは、Proxy-Authenticate フィールドを使用して認証を要求した次のインバウンドプロキシにのみ適用されます。チェーンで複数のプロキシが使用される場合、Proxy-Authorization ヘッダーフィールドは、資格情報を受信することを期待していた最初のインバウンドプロキシによって消費されます。プロキシが協力して特定のリクエストを認証するメカニズムである場合、プロキシはクライアントリクエストから次のプロキシに資格情報をリレーしてもよい (MAY) です。
5.5. Request Context (リクエストコンテキスト)
以下のリクエストヘッダーフィールドは、リクエストの背後にあるユーザー、ユーザーエージェント、およびリソースに関する情報を含む、リクエストコンテキストに関する追加情報を提供します。
5.5.1. From (差出人)
From ヘッダーフィールドには、リクエストユーザーエージェントを制御する人間のユーザーのインターネット電子メールアドレスが含まれています。アドレスは、[RFC5322] の Section 3.4 の "mailbox" で定義されているように、機械で使用可能である必要があります。
From = mailbox
例は次のとおりです：
From: [email protected]
From ヘッダーフィールドは、非ロボットユーザーエージェントによってはほとんど送信されません。ユーザーエージェントは、ユーザーが明示的に設定しない限り、From ヘッダーフィールドを送信すべきではありません (SHOULD NOT)。これは、ユーザーのプライバシーの利益やサイトのセキュリティポリシーと矛盾する可能性があるためです。
ロボットユーザーエージェントは、サーバーで問題が発生した場合（たとえば、ロボットが過剰、不要、または無効なリクエストを送信している場合）、ロボットの実行を担当する人に連絡できるように、有効な From ヘッダーフィールドを送信すべきです (SHOULD)。
サーバーは、アクセス制御または認証に From ヘッダーフィールドを使用すべきではありません (SHOULD NOT)。ほとんどの受信者は、フィールド値が公開情報であると想定するためです。
5.5.2. Referer (リファラー)
Referer [原文ママ] ヘッダーフィールドにより、ユーザーエージェントは、ターゲット URI が取得されたリソースの URI 参照を指定できます（つまり、「referrer」（リファラー）、ただしフィールド名のスペルは間違っています）。ユーザーエージェントは、Referer フィールド値を生成するときに、URI 参照 [RFC3986] のフラグメントおよびユーザー情報コンポーネント（もしあれば）を含めてはなりません (MUST NOT)。
Referer = absolute-URI / partial-URI
Referer ヘッダーフィールドにより、サーバーは他のリソースへのバックリンクを生成して、シンプルな分析、ログ記録、最適化されたキャッシュなどを行うことができます。また、保守のために古いリンクや誤って入力されたリンクを見つけることもできます。一部のサーバーは、Referer ヘッダーフィールドを他のサイトからのリンク（いわゆる「ディープリンク」）を拒否したり、クロスサイトリクエストフォージェリ (CSRF) を制限したりする手段として使用しますが、すべてのリクエストに含まれているわけではありません。
例：
Referer: http://www.example.org/hypertext/Overview.html
ターゲット URI が独自の URI を持たないソース（たとえば、ユーザーキーボードからの入力、またはユーザーのブックマーク/お気に入り内のエントリ）から取得された場合、ユーザーエージェントは Referer フィールドを除外するか、値 "about:blank" で送信しなければなりません (MUST)。
参照リソースの識別子が個人情報（アカウント名など）を明らかにする場合、または機密にすべきリソース（ファイアウォールの背後や保護されたサービスの内部など）である場合、Referer フィールドはリクエストコンテキストまたはユーザーの閲覧履歴に関する情報を明らかにする可能性があり、これはプライバシー上の懸念です。ほとんどの汎用ユーザーエージェントは、参照リソースがローカルの "file" または "data" URI である場合、Referer ヘッダーフィールドを送信しません。参照ページが安全なプロトコルで受信された場合、ユーザーエージェントは安全でない HTTP リクエストで Referer ヘッダーフィールドを送信してはなりません (MUST NOT)。追加のセキュリティの考慮事項については、Section 9.4 を参照してください。
一部の仲介者は、発信リクエストから Referer ヘッダーフィールドを無差別に削除することが知られています。これには、CSRF 攻撃に対する保護を妨げるという不幸な副作用があり、ユーザーにとってはるかに有害である可能性があります。Referer での情報開示を制限したい仲介者およびユーザーエージェント拡張機能は、内部ドメイン名を仮名に置き換えたり、クエリおよび/またはパスコンポーネントを切り捨てたりするなど、特定の編集に変更を制限すべきです。フィールド値がリクエストターゲットと同じスキームおよびホストを共有する場合、仲介者は Referer ヘッダーフィールドを変更または削除すべきではありません (SHOULD NOT)。
5.5.3. TE (転送エンコーディング)
TE ヘッダーフィールドは、chunked 以外に、クライアントがレスポンスで受け入れる用意がある転送コーディングと、クライアントが chunked 転送コーディングでトレーラーフィールドを受け入れる用意があるかどうかを示します。
TE フィールド値は、カンマで区切られた転送コーディング名のリストで構成され、それぞれがオプションのパラメータ（[RFC7230] の Section 4 で説明）を許可し、および/またはキーワード "trailers" を許可します。
TE = #( t-codings )
t-codings = "trailers" / ( transfer-coding [ t-ranking ] )
t-ranking = OWS ";" OWS "q=" rank
rank = ( "0" [ "." 0*3DIGIT ] )
/ ( "1" [ "." 0*3("0") ] )
以下は TE 使用の 3 つの例です。
TE: deflate
TE:
TE: trailers, deflate;q=0.5
TE ヘッダーフィールドは直接接続にのみ適用されます。したがって、TE が HTTP/1.1 メッセージに存在するときはいつでも、キーワード "TE" を Connection ヘッダーフィールド（[RFC7230] の Section 6.1）内で提供しなければなりません (MUST)。
サーバーは、Accept-Encoding (Section 5.3.4) と同じ規則を使用して転送コーディングが受け入れ可能かどうかをテストします。ただし、"trailers" という名前のエンコーディングは常に受け入れ可能であり、"q" パラメータ値が 0 の転送コーディングは受け入れられません。
TE ヘッダーフィールドは直接接続にのみ適用されるため、TE の送信者は、そのセマンティクスをサポートしない仲介者によって TE フィールドが転送されるのを防ぐために、Connection ヘッダーフィールド（[RFC7230] の Section 6.1）内に "TE" 接続オプションも送信しなければなりません (MUST)。
5.5.4. User-Agent (ユーザーエージェント)
User-Agent ヘッダーフィールドには、リクエストを発信したユーザーエージェントに関する情報が含まれています。これは、報告された相互運用性の問題の範囲を特定したり、特定のユーザーエージェントの制限を回避またはカスタマイズするためにレスポンスを調整したり、ブラウザまたはオペレーティングシステムの使用に関する分析のために、サーバーによってよく使用されます。ユーザーエージェントは、特に設定されていない限り、各リクエストで User-Agent フィールドを送信すべきです (SHOULD)。
User-Agent = product *( RWS ( product / comment ) )
User-Agent フィールド値は、1 つ以上の製品識別子で構成され、それぞれの後にゼロ個以上のコメント（[RFC7230] の Section 3.2）が続きます。これらが一緒にユーザーエージェントソフトウェアとその重要なサブ製品を識別します。慣習により、製品識別子は、ユーザーエージェントソフトウェアを識別するための重要性の降順でリストされます。各製品識別子は、[RFC7230] の Section 5.5.3 で定義されているように、名前とオプションのバージョンで構成されます。
例：
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
ユーザーエージェントは、不必要に詳細な User-Agent フィールドを生成すべきではなく (SHOULD NOT)、第三者によるサブ製品の追加を制限すべきです (SHOULD)。過度に長く詳細な User-Agent フィールド値は、リクエストのレイテンシを増加させ、ユーザーが望まないのに識別されるリスク（「フィンガープリンティング」）を高めます。
同様に、実装は、それらとの互換性を宣言するために他の実装の製品トークンを使用しないことが推奨されます。これは、フィールドの目的を回避するためです。ユーザーエージェントが異なるユーザーエージェントに偽装している場合、受信者は、実際に使用されているユーザーエージェントではうまく機能しない可能性があっても、ユーザーがその識別されたユーザーエージェント用に調整されたレスポンスを意図的に見たいと望んでいると想定できます。