Accept
パラメーターは、サーバーから送信されるクライアント応答で予期されるデータ型を定義するため、応答ヘッダーとして使用されることを理解しています。
私の質問はContent-type
に関するもので、送信されたリクエストのボディ形式を定義するためにクライアントによって使用され、常にクライアントリクエストの一部として使用したため、Accept
でヘッダーを設定するクライアントリクエストがありますおよびContent-type
。そして最近、私はContent-type
が応答ヘッダーで定義されている(サーバーから送信された)プロジェクトに出会いました。だから私の質問は次のとおりです。Content-type
は、クライアント要求ヘッダーの一部として、またはサーバー応答ヘッダーの一部として設定する必要がありますか、それとも両方に設定できますか?
関連するRFCを読んでください。この場合 7231 :
ユーザーエージェントは、「Accept」ヘッダーフィールドを使用して、response許容可能なメディアタイプを指定できます。
「Content-Type」ヘッダーフィールドは、関連付けられた表現のメディアタイプを示します
Accept
は、クライアントが受け入れることができるサーバーからの応答の種類を示します。 Content-type
は常に現在の要求または応答の内容に関するものです。
そのため、リクエストにペイロードがない場合は、コンテンツタイプのリクエストヘッダーを使用しません。
HTTPクライアントはAcceptヘッダーを使用して、応答として予期/優先するコンテンツのタイプをサーバーに伝えます。コンテンツタイプは、クライアントとサーバーの両方で使用して、要求(クライアント)または応答(サーバー)のデータの形式を識別できるため、他の部分が情報を正しく解釈するのに役立ちます。
TL; DR
エンティティヘッダーContent-Type
は、リソースのメディアタイプを示すために使用されます。応答では、Content-Type
ヘッダーは、返されたコンテンツのコンテンツタイプが実際に何であるかをクライアントに伝えます。 POSTまたはPUTなどのリクエストでは、クライアントは実際に送信されるデータのタイプをサーバーに伝えます。
詳細な回答
正しく注意するように、HTTPクライアントはAccept
ヘッダーを使用して、受け入れ可能な応答メディアタイプをサーバーに通知します。サーバーは、順番に、クライアントにメディアタイプが実際に返されるものを伝えるContent-Type
ヘッダーを含む応答を送り返します。
これで、Content-Type
ヘッダーもリクエストとレスポンスに含めることができます。どうして? POSTまたはPUTリクエストについて考えてみてください。これらのリクエストタイプでは、クライアントは実際にリクエストの一部として大量のデータをサーバーに送信しており、Content-Type
ヘッダーはサーバーはデータが実際に何であるか、したがってサーバーがそれをどのように解析するかを決定します。
受け入れるのは
ここに私のリクエストがあり、このレスポンス形式を(受け入れたい)
コンテンツタイプは
これが私の要求(または応答)であり、これ(Content-Type)は私の要求(または応答)で送信するコンテンツの形式です