HTTPによるプロトコルの構築

本書におけるキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", および "OPTIONAL" は、すべて大文字で示される場合に限り BCP 14 に記載されたとおりに解釈されます。[RFC2119] [RFC8174] を参照してください。

アプリケーションは、上記のHTTP使用基準を満たさなくてもHTTPに依存することができます。たとえば、メッセージ形式の一部を再定義したくないがプロトコルの他の動作を変更したい場合や、アプリケーション固有のメソッドを使用したい場合があります。

そうすることでプロトコル動作をより自由に変更できますが、セクション 3で概説されている利点の少なくとも一部が失われます。大多数のHTTP実装はこれらの変更に容易に適応できないためです。マインドシェア（広く認知されていること）の利点も失われます。

そのような仕様は MUST NOT HTTPのURIスキーム、トランスポートポート、ALPNプロトコルID、またはIANAレジストリを使用してはなりません。代わりに、それら自身のものを定義することが推奨されます。

HTTPの価値の多くはその汎用的なセマンティクスにあります。つまり、HTTPによって定義されるプロトコル要素は、特定の文脈に限定されず、あらゆるリソースに適用可能であるという点です。アプリケーション固有のセマンティクスは、ステータスコードやメソッドではなく、メッセージコンテンツやヘッダーフィールドで表現するのが適切です（とはいえ、ステータスコードやメソッドにもアプリケーション状態に関連する汎用的セマンティクスはあります）。

この汎用とアプリケーション固有のセマンティクスの分離により、HTTPメッセージは共通のソフトウェア（例: HTTPサーバー、中間機、クライアント実装、キャッシュ）によってアプリケーションを理解することなく処理され得ます。また、特定のアプリケーションについての専門知識がなくてもHTTPのセマンティクスの知識を活用できるようになります。

したがって、HTTPを使用するアプリケーションは、メソッド、ステータスコード、既存のヘッダーフィールドなどの汎用的なプロトコル要素のセマンティクスを再定義、細分化、上書きしてはなりません（MUST NOT）。代わりに、仕様はそのアプリケーション固有のプロトコル要素、すなわちHTTPリソースに焦点を当てるべきです。

POSTリクエストは必ず201 (Created) の応答を返さなければならない。

このような記述は、実際のデプロイメントではステータスコードが異なる理由が多数あるにもかかわらず、クライアントに対して常に201が返るという期待を生じさせます。例えば、認証を要求するプロキシがある場合や、サーバー側のエラー、リダイレクションなどが考えられます。クライアントがこれらを想定していないと、アプリケーションのデプロイメントは脆弱になります。

詳細は セクション 4.2 を参照してください。

もう一つの一般的な慣行は、HTTPサーバーの名前空間（またはその一部）が単一のアプリケーション専用であると仮定することです。これはその空間にアプリケーション固有の特別なセマンティクスを重ねることになり、他のアプリケーションがそれを使用することを妨げます。

[BCP190] で説明されているように、標準によるURL空間の一部の「占拠」はサーバー自身のリソースに対する権限を奪い、デプロイメントの問題を引き起こす可能性があるため、標準化において望ましくない慣行です。

代わりに、URIコンポーネント（パスなど）を静的に定義するのではなく、HTTPを使用するアプリケーションはリンク [WEB-LINKING] を定義・使用して、デプロイの柔軟性を確保することがRECOMMENDEDです。

このようにランタイムのリンクを使用することには、特にアプリケーションが複数の実装やデプロイメントを持つ場合（標準化されることの多いケース）に、多くの利点があります。

例えば、リンクでナビゲートすることでリクエストがリダイレクトのオーバーヘッドなしに別のサーバーにルーティングされ、複数のマシンにまたがるデプロイメントをよくサポートできます。

リンクを使用することで、同じサーバー上で異なるアプリケーションを「混在」させることが可能になり、リンクを含むドキュメント自体にターゲットに関する情報を含めることで拡張性、バージョニング、機能管理の自然な仕組みが提供されます。

また、リンクを使用することはWebで見られるキャッシュ無効化の一形態も提供します。リソースの状態が変わったときに、アプリケーションは影響を受けるリンクを変更して常に新しいコピーが取得されるようにできます。

詳細は セクション 4.4 を参照してください。

• メッセージのフレーミング
• 多重化（HTTP/2 [HTTP/2] および HTTP/3 [HTTP/3] において）
• TLSとの統合
• 中間体（プロキシ、ゲートウェイ、コンテンツ配信ネットワーク(CDN)）のサポート
• クライアント認証
• フォーマット、言語、その他の機能に対するコンテンツネゴシエーション
• サーバーのスケーラビリティ、レイテンシおよび帯域幅の削減、信頼性のためのキャッシング
• URL空間の豊かな利用によるアクセス制御の粒度
• レスポンスの一部を選択的に要求するための部分コンテンツ
• Webブラウザを用いてアプリケーションと容易に対話できる能力

HTTPを使用するアプリケーションは、これらの機能を活用して、ユーザーがそれらの恩恵を最大限に受けられるようにし、さまざまな状況でデプロイできるようにすることが奨励されます。本書は特定の機能の使用を義務付けるものではありません。適切な設計上のトレードオフは状況に強く依存するためです。しかし、セクション 4の実践に従うことが良い出発点となります。

仕様はHTTPの主要な参照として[HTTP]を使用すべきです; 特定の機能が明示的に指定されているなどの特別な理由がない限り、HTTPスイート内のすべての仕様を参照する必要はありません。

HTTPはホップバイホップのプロトコルであるため、接続はアプリケーションが制御していない実装（プロキシ、CDN、ファイアウォールなど）によって扱われる可能性があります。特定のHTTPバージョンを必須とするとこれらの状況での利用が困難になり、相互運用性を損ないます。したがって、HTTPを使用するアプリケーションが使用するHTTPの最低バージョンを指定することは推奨されません。

ただし、アプリケーションのデプロイメントが特定のHTTPバージョン（例えばHTTP/2の多重化）を利用することで利益を得る場合は、その旨を記述すべきです。

HTTPを使用するアプリケーションは、プロトコルの進化能力を保持するために、最大バージョンを指定してはなりません (MUST NOT )。

GET /thing HTTP/1.1
Host: example.com
Accept: application/things+json
User-Agent: Foo/1.0

HTTP/1.1 200 OK
Content-Type: application/things+json
Content-Length: 500
Server: Bar/2.2

[content here]

• メディアタイプ [RFC6838]、しばしばJSONのようなフォーマット慣習に基づく;
• HTTPヘッダフィールド（セクション 4.7参照）; および
• リンク関係によって識別されるリソースの動作 [WEB-LINKING]。

• GETを使用した複数のメディアタイプで識別される形式でのリソース状態の取得;
• POSTまたはPUTを使用したリソースの作成または更新（適切に識別されたリクエストコンテンツ形式で）;
• POSTを用いたデータ処理（識別されたリクエストおよびレスポンスのコンテンツ形式を使用）; および
• DELETEを使用したリソースの削除。

"example-widget"リンク関係タイプでリンクされたリソースはWidgetです。Widgetの状態は"application/example-widget+json"形式で取得でき、同じリンクへPUTすることで更新できます。Widgetリソースは削除できます。

Widget表現のExample-Countレスポンスヘッダフィールドは、送信者が保持するWidgetの数を示します。

"application/example-widget+json"形式は、Widgetの状態を表すJSON [RFC8259]形式です。Linkヘッダフィールドの値に示されたリンクで"example-other-info"リンク関係タイプにある関連情報へのリンクを含みます。

アプリケーションはURIテンプレート [URI-TEMPLATE] の使用を指定して、クライアントがランタイムデータに基づいてURLを生成できるようにすることもできます。

アプリケーションがクライアントに期待する動作は、相互運用性の問題を避けるためにWebブラウザの期待と密接に整合しているべきです。

その一つの方法は、ブラウザがHTTPに対して使用する抽象である[FETCH]に基づいて定義することです。

リダイレクト処理:

アプリケーションはリダイレクトをどのように扱うことを期待するかを指定する必要があります。詳細はセクション 4.6.1を参照してください。

クッキー:

HTTPを使用するアプリケーションは、クッキーが必要な場合はクッキー仕様 [COOKIES] を明示的に参照するべきです。

証明書:

HTTPを使用するアプリケーションは、HTTPSが使用される場合にTLS証明書がSection 4.3.4 に従って検証されることを指定するべきです。

HTTPを使用するアプリケーションは、通常ネゴシエートされるHTTP機能をクライアントが静的にサポートすることを要求すべきではありません。例えば、あるコンテンツコーディングをクライアントが静的にサポートすることを要求する（[HTTP]、Section 8.4.1）代わりに、それをネゴシエートする（[HTTP]、Section 12.5.3）べきです。前者は、そうでなければ適合するクライアントがアプリケーションと相互運用できなくなることを意味します。とはいえ、アプリケーションはそのような機能の実装を奨励することはできます。

HTTPでは、クライアントがやり取りするリソースはURLで識別されます [URL]。[BCP190] が説明するように、URLの一部はサーバーの所有者（"authority"）の制御下に置かれるよう設計されており、これがデプロイの柔軟性を与えます。

これは多くの場合、HTTPを使用するアプリケーションの仕様が固定されたアプリケーションURLやパスを含まないことを意味します。単一デプロイ向けAPIの仕様で"/app/v1"のようなパスプレフィックスを指定するのは一般的ですが、IETFの仕様でそれを行うのは不適切です。

したがって、仕様作成者はクライアントがアプリケーションのURLを発見する手段を提供する必要があります。加えて、どのURLスキームを使用するか、専用ポートを用いるかHTTPのポートを再利用するかを指定する必要があります。

HTTPを使用するアプリケーションは、GET、POST、PUT、DELETE、PATCHのような登録済みのHTTPメソッドの使用に限定しなければなりません (MUST)。

新しいHTTPメソッドはまれであり、IETFレビューでの登録が必要です（"HTTP Method Registry"）。また、それらは汎用である必要があります。つまり、特定のアプリケーションのリソースだけでなく、潜在的にすべてのリソースに適用可能でなければなりません。

歴史的に一部のアプリケーション（例: [RFC4791]）はアプリケーション固有のメソッドを定義してきましたが、[HTTP] は現在これを禁止しています。

新しいメソッドが必要だと著者が考える場合は、早期にHTTPコミュニティ（例: <mailto:ietf-http-wg@w3.org> メーリングリスト）と関わり、アプリケーション仕様の一部としてではなく別個のHTTP拡張として提案を文書化することが推奨されます。

HTTPステータスコードはキャッシュや中間体、クライアントなどの汎用HTTPコンポーネントおよびアプリケーション自体の利便のためにセマンティクスを伝えます。しかし、アプリケーションはその使用においていくつかの落とし穴に直面します。

まず、ステータスコードはしばしばアプリケーション以外のコンポーネントによって生成されます。例えば、ネットワークエラーが発生した場合、キャプティブポータルやプロキシ、CDNが存在する場合、またはサーバーが過負荷状態にある、あるいは攻撃を受けていると考える場合などです。特定のエラー条件が発生したときに汎用クライアントソフトウェアがステータスコードを生成することさえあります。その結果、アプリケーションが特定のステータスコードに特定のセマンティクスを割り当てると、クライアントはそのステータスコードがアプリケーションではなく汎用コンポーネントによって生成されたために状態を誤認する可能性があります。

さらに、アプリケーションのエラーを個別のHTTPステータスコードに1対1でマッピングすると、適用可能なHTTPステータスコードの有限の空間が枯渇する状況に陥りやすいです。これにより、新しいアプリケーション固有のステータスコードを作成したり、既存のステータスコードをその意味と乖離して使用したりするなどの悪い慣行につながります。

代わりに、HTTPを使用するアプリケーションは、最も適切なステータスコードを使用し、疑わしい場合は一般的なステータスコード（200、400、500など）を寛大に使うべきです。重要なのは、ステータスコードとアプリケーションエラーの間に1対1の関係を指定しないことであり、これにより前述の枯渇問題を回避できます。

同じステータスコードにマップされた複数のエラー状態を区別し、前述の誤帰属の問題を避けるために、HTTPを使用するアプリケーションはレスポンスのメッセージ内容および/またはヘッダフィールドでより細かいエラー情報を伝えるべきです。[PROBLEM-DETAILS] はその一つの方法を提供します。

登録されたHTTPステータスコードの集合は拡張され得るため、HTTPを使用するアプリケーションはクライアントがすべての適用可能なステータスコードを優雅に扱えるようにすべきであることを明示するべきです（つまり、あるステータスコードを認識しないクライアントはそのコードの一般的なn00のセマンティクスにフォールバックできること; 例えば499を認識しないクライアントは安全に400 (Bad Request) として扱える等）。これは将来的に完全でない洗い出しリストを作成するより好ましいです。

HTTPを使用するアプリケーションはHTTPステータスコードのセマンティクスを再定義してはなりません (MUST NOT)。理由句を特定のものにすることを要求するのは推奨されません; 理由句はHTTPにおいて機能を持たず、実装によって保持される保証がなく、HTTP/2のメッセージ形式ではまったく運ばれません。

アプリケーションは登録済みのHTTPステータスコードのみを使用しなければなりません (MUST)。メソッドと同様に、新しいHTTPステータスコードはまれであり、IETFレビューで登録されることが要求されます。HTTPステータスコードは汎用的であり、特定のアプリケーションのリソースだけでなく潜在的にすべてのリソースに適用可能である必要があります。

著者が新しいステータスコードが必要だと考える場合は、早期にHTTPコミュニティ（例: <mailto:ietf-http-wg@w3.org> メーリングリスト）と関わり、アプリケーション仕様の一部としてではなく別個のHTTP拡張として提案を文書化することが推奨されます。

• そのフィールドが中間体にとって有用である（中間体はしばしばメッセージコンテンツの解析を避けたい）および/または
• そのフィールドが汎用のHTTPソフトウェア（クライアント、サーバーなど）にとって有用である、および/または
• 値をメッセージコンテンツに含めることが不可能である（通常はフォーマットがそれを許さないため）。

上記の条件が満たされない場合、アプリケーション固有の情報は通常メッセージ内容やURLクエリ文字列など他の場所で伝える方が良いです。

新しいヘッダフィールドは登録されなければなりません (Section 16.3 に従って) 。

新しいヘッダフィールドを作成する際に検討すべきガイドラインは Section 16.3.2 を参照してください。[STRUCTURED-FIELDS] は新しいヘッダフィールドに共通の構造を提供し、その解析と処理における多くの問題を回避します; 新しいヘッダフィールドでの使用が推奨されます。

ヘッダフィールド名は短くすることが推奨されます（フィールド圧縮が使われていてもオーバーヘッドがあるため） が、適切に具体的であるべきです。特に、ヘッダフィールドがアプリケーション固有である場合、ハイフンで区切ったアプリケーション識別子をプレフィックスとして使うことができます。

例えば、"example"アプリケーションが3つのヘッダフィールドを作成する必要がある場合、それらは "example-foo", "example-bar", "example-baz" と呼ばれるかもしれません。主な動機はより一般的なフィールド名の消費を避けることであり、アプリケーションのために名前空間の一部を予約することではない点に注意してください; 関連する考慮事項は [RFC6648] を参照してください。

既存のHTTPヘッダフィールドのセマンティクスは、登録を更新したり（許される場合は）それらに対する拡張を定義したりしない限り再定義してはなりません (MUST NOT)。例えば、アプリケーションがLocationヘッダフィールドに特定の文脈で特別な意味を持たせることはできません。

ヘッダフィールドとHTTPキャッシュの相互作用については セクション 4.9 を参照してください。特に、レスポンスを選択するために使用されるリクエストヘッダフィールド（Section 4.1 に従う）は影響を及ぼすため注意が必要です。

アプリケーション状態を運ぶヘッダフィールド（例: Cookie）に関する考慮事項については セクション 4.10 を参照してください。

メッセージ内容の一般的な構文慣例にはJSON [JSON]、XML [XML]、およびCBOR [RFC8949] などがあります。これらの使用に関するベストプラクティスは本書の範囲外です。

アプリケーションは定義する各フォーマットについて個別のメディアタイプを登録すべきです; これによりそれらを一意に識別し、使用のネゴシエーションが可能になります。詳細は [RFC6838] を参照してください。

HTTPキャッシュ [HTTP-CACHING] は、アプリケーションでHTTPを使用する主な利点の一つです。これによりスケーラビリティが向上し、レイテンシが削減され、信頼性が向上します。さらに、HTTPキャッシュはブラウザや他のクライアント、ネットワーク上のフォワードおよびリバースプロキシ、CDN、サーバーソフトウェアの一部として容易に利用できます。

HTTPを使用するアプリケーションがキャッシュの利点を活用するよう設計されていない場合でも、キャッシュがレスポンスをどのように扱うかを考慮して、ネットワーク、サーバー、クライアント、または途中のインフラに差し挟まれた場合でも正しい動作が保たれるようにする必要があります。

アプリケーションは状態を識別するため、またはリクエストを文脈化するためにクライアント固有データを保存するためにステートフルなクッキー [COOKIES] を使用できます。

使用する場合、クッキーのスコープと使用法を慎重に指定することが重要です; アプリケーションが機密データや機能を公開する（例: 周辺的権限として動作する）場合、悪用の可能性があります。軽減策には、クライアントの意図を保証するためのリクエスト固有のトークンの使用が含まれます。

クライアントはしばしばタスクを実行するために複数のリクエストを送信する必要があります。

HTTP/1 [HTTP/1.1] では、並列リクエストは通常複数の接続を開くことでサポートされます。接続の輻輳制御が調整されないため、同時接続が多すぎるとアプリケーションのパフォーマンスに影響を与える可能性があります。さらに、どの接続をいつ使ってリクエストを発行するかを決定するのが難しい場合があり、これもパフォーマンスに影響します。

HTTP/2 [HTTP/2] および HTTP/3 [HTTP/3] はアプリケーションに多重化を提供し、複数接続を使用する必要性を排除します。しかし、サーバーがレスポンスの優先順位をどのように選ぶかによってアプリケーションのパフォーマンスは依然として大きく影響され得ます。アプリケーションによっては、サーバーがレスポンスの優先度を決定する方が良い場合や、クライアントがサーバーに優先度をヒントとして示す方が良い場合があります（例: [HTTP-PRIORITY]）。

すべてのHTTPバージョンにおいて、リクエストは独立して行われます — 二つのリクエストの相対的な順序が処理順序を保証すると期待してはなりません。これらは中間体によって多重化されたり、異なるオリジンサーバーに送られたり、サーバーが異なる順序で処理したりする可能性があるためです。二つのリクエストに厳密な順序が必要な場合、結果を確実にする唯一の信頼できる方法は、最初のリクエストの最終レスポンスが開始されたときに二番目のリクエストを発行することです。

アプリケーションは単一のトランスポート接続上の別々のリクエスト間の関係について仮定してはなりません (MUST NOT)。そうするとHTTPのステートレスプロトコルとしての多くの仮定を壊し、相互運用性、セキュリティ、運用性、進化に問題を引き起こします。

アプリケーションはクライアントを識別するためにHTTP認証（Section 11）を使用できます。[RFC7617] によれば、Basic認証スキームはチャネルが安全でない限り（例: "https" URIスキームを使う）機密情報や価値のある情報を保護するのに適していません。同様に [RFC7616] はDigest認証スキームを安全なチャネル上で使用することを要求します。

HTTPSでは、クライアントは証明書を用いて認証されることもあります [RFC8446] が、そのような認証は基盤となるトランスポート接続に本質的にスコープされる点に注意してください。その結果、クライアントは認証された状態がレスポンスの準備に使用されたかどうかを知る方法がありません（ただしVary: * や private キャッシュディレクティブは部分的な指標を与えることがあります）。特に、明示的に未認証のレスポンスを得る唯一の方法は新しい接続を開くことです。

使用する場合、認証のスコープと使用法を慎重に指定することが重要です; アプリケーションが機密データや機能を公開する（例: 周辺的権限として動作する）場合、悪用の可能性があります。軽減策として、クライアントの意図を保証するためのリクエスト固有のトークンの使用が含まれます。

アプリケーションがWebブラウザで使用される意図がなくても、そのリソースはブラウザや他のHTTPクライアントから引き続きアクセス可能であり続けます。これは、HTTPを使用するすべてのアプリケーションがブラウザとの相互作用、特にセキュリティに関してどのように動作するかを考慮する必要があることを意味します。

例えば、アプリケーションの状態がPOSTリクエストで変更できる場合、Webブラウザは任意のWebサイトからのクロスサイトリクエストフォージェリ（CSRF）を簡単に誘発される可能性があります。

また、攻撃者がアプリケーションのリソースから返されるコンテンツを制御すると（例えば、リクエストの一部がレスポンスに反映される、またはレスポンスに攻撃者が変更できる外部情報が含まれる場合）、ブラウザにコードを注入してオリジンとしてデータや機能にアクセスすることが可能になります。これはクロスサイトスクリプティング（XSS）攻撃として知られています。

これは考慮すべき問題の一部に過ぎません。一般に最良のアプローチは、アプリケーションを実際にWebアプリケーションとして扱い、その安全な開発のためのベストプラクティスに従うことです。

• Content-Typeヘッダフィールドでアプリケーション固有のメディアタイプを使用し、クライアントがそれを使用しない場合に失敗するよう要求すること。
• X-Content-Type-Options: nosniff [FETCH] を使用して、攻撃者に制御されたコンテンツがブラウザによってアクティブコンテンツとして解釈されるのを防ぐこと。
• Content-Security-Policy [CSP] を使用して、HTMLやPDFのような実行可能なスクリプトを持つアクティブコンテンツの能力を制約し、XSS攻撃を軽減すること。
• Referrer-Policy [REFERRER-POLICY] を使用して、URL内の機密データがRefererリクエストヘッダフィールドで漏洩するのを防ぐこと。
• クッキーに 'HttpOnly' フラグを使用して、クッキーがブラウザのスクリプト言語から露出しないようにすること [COOKIES]。
• 認証トークンやパスワードなどの機密情報に対して圧縮を使用することを避けること。ブラウザが提供するスクリプト環境により攻撃者が圧縮領域を繰り返し探査することが可能であり、通信のネットワーク経路に攻撃者がアクセスできる場合、その情報を回復するためにこの機能を悪用され得ます。

それらがどのようにデプロイされることを意図しているかに応じて、HTTPを使用するアプリケーションの仕様はこれらのメカニズムの使用を特定の方法で要求するか、あるいはセキュリティ考慮事項で指摘するだけにとどめるかもしれません。

HTTP/1.1 200 OK
Content-Type: application/example+json
X-Content-Type-Options: nosniff
Content-Security-Policy: default-src 'none'
Cache-Control: max-age=3600
Referrer-Policy: no-referrer

[content]

アプリケーションがブラウザ互換性を目標とする場合、クライアントとの対話はブラウザがHTTPに対して使用する抽象である[FETCH]に基づいて定義されるべきです; これにより多くのベストプラクティスが強制されます。

多くのHTTP機能がオリジンにスコープされるため [RFC6454]、アプリケーションは同じオリジンサーバーを使用する他のアプリケーション（Webブラウジングを含む）とのデプロイがどのように相互作用するかも考慮する必要があります。

例えば、クッキー [COOKIES] がアプリケーション状態を運ぶために使用される場合、それらはデフォルトでオリジンへのすべてのリクエストと共に送信されます（パスでスコープされていない限り）、そしてアプリケーションはオリジン上の他のアプリケーションからのクッキーも受け取る可能性があります。これによりセキュリティ問題やクッキー名の衝突が発生する可能性があります。

これらの問題の一つの解決策は、アプリケーションに専用のホスト名を要求して固有のオリジンを持たせることですが、複数のアプリケーションを単一のホスト名にデプロイできるようにすることが望ましいことが多いです; そうすることで最も多くのデプロイの柔軟性が得られ、それらを"混在"させることができます（詳細は [BCP190] を参照）。

したがって、HTTPを使用するアプリケーションはオリジン上で複数のアプリケーションを許容するよう努めるべきです。具体的には、クッキー、HTTP認証領域 [HTTP]、またはその他のオリジン全体に関わるHTTPメカニズムを指定する際、HTTPを使用するアプリケーションは特定の名前の使用を強制するのではなく、デプロイメント側でそれらを設定できるようにすべきです。部分的にオリジンにスコープする方法を検討し、指定されたメカニズムを用いることを考慮してください。

現代のWebブラウザは一つのオリジンからのコンテンツが別のオリジンのリソースにアクセスする能力を制約してプライベート情報の漏洩を防いでいます。その結果、ブラウザにクロスオリジンデータを公開したいアプリケーションはCORSプロトコルを実装する必要があります; 詳細は [FETCH] を参照してください。

• サーバープッシュはホップバイホップです; つまり中間体によって自動的に転送されません。したがって、プロキシ、リバースプロキシ、CDNと容易に（または全く）動作しない可能性があります。
• サーバープッシュは誤用された場合にHTTPのパフォーマンスに悪影響を与える可能性があり、特にクライアントが実際に要求したリソースと競合する場合に顕著です。
• サーバープッシュはキャッシュとの相互作用に関して異なるクライアントで異なる実装があり、機能は様々です。
• サーバープッシュのAPIは一部の実装で現在利用できず、他の実装では大きく異なります。特にブラウザ向けの現在のAPIはありません。
• サーバープッシュはHTTP/1.1やHTTP/1.0ではサポートされていません。
• サーバープッシュはHTTPの"コア"セマンティクスの一部ではないため、将来のバージョンのプロトコルでサポートされない可能性があります。

クライアントが完全なレスポンスを受け取る前に関連する作業を行えるように最適化したいアプリケーション（例えば、その中に含まれる可能性の高いリンクを事前取得する等）は、103 (Early Hints) ステータスコードの使用を検討すると有益かもしれません; [RFC8297] を参照してください。

サーバープッシュを直接使用するアプリケーションは、クロスオリジンプッシュ攻撃を避けるために [HTTP/2]、Section 8.4 に記載されている権限に関する要件を順守する必要があります。

アプリケーションプロトコルに新機能を導入したり既存のものを変更したりすることがしばしば必要になります。

• 新機能を実装するリソースのURLを識別するために、別個のリンク関係タイプ [WEB-LINKING] を使用すること。
• 新機能を可能にするフォーマットを識別するために、別個のメディアタイプ [RFC6838] を使用すること。
• メッセージ内容の外で新機能を実装するために、別個のHTTPヘッダフィールドを使用すること。

HTTP クライアントはサーバーにさまざまな情報を公開する可能性があります。アプリケーションの操作の一部として明示的に送信される情報（例えば名前やユーザー入力データ）や「ワイヤ上」の情報（これが セクション 4.4.2 で "https" が推奨される理由の一つです）に加えて、より明白でない手段によって収集される情報もあり、しばしばユーザーの活動を時間を通じて結び付けることで行われます。

これにはセッション情報、フィンガープリンティングによるクライアントの追跡、コード実行などが含まれます。

セッション情報にはクライアントの IP アドレス、TLS セッションチケット、クッキー、クライアントキャッシュに保存された ETag、およびその他の状態を持つメカニズムが含まれます。アプリケーションは、避けられないか動作に必要でない限りセッションメカニズムの使用を回避することが勧められます。必要な場合は、これらのリスクを文書化する必要があります。使用する場合は、実装がそのような状態をクリアできるようにすることが奨励されます。

フィンガープリンティングは、クライアントのメッセージや振る舞いの固有の側面を利用して異なるリクエストや接続を結び付けます。例えば User-Agent リクエストヘッダは実装に関する特定の情報を伝え、Accept-Language リクエストヘッダはユーザーの優先言語を伝えます。これらのマーカーを組み合わせることでクライアントを一意に識別でき、データに対するコントロールに影響を与え得ます。その結果、アプリケーションはクライアントがリクエストで機能に必要な情報のみを送信するよう指定することが推奨されます。

最後に、アプリケーションがコード実行の機能を公開する場合、環境を観察できる能力はクライアントのフィンガープリンティングや機密データ（セッション情報を含む）の取得・操作の機会として悪用され得るため、細心の注意が必要です。例えば高精度タイマーへのアクセス（間接的であっても）は基盤となるハードウェアのプロファイリングに利用され、システムの一意識別子を作り得ます。可能な限りモバイルコードの使用を避けることが勧められ、避けられない場合はその結果として生じるシステムのセキュリティ特性を注意深く精査する必要があります。