私が理解している限り、コンテンツタイプを設定する場所は2つあります。
これは、すべてのgetリクエスト（クライアント側）にコンテンツタイプを設定する必要がない、または設定すべきでないことを意味しますか？そして、もし私ができる、またはすべきなのはどのようなコンテンツタイプでしょうか？
また、クライアントのコンテンツタイプが、クライアントが受信するコンテンツのタイプを指定しているという投稿もいくつか読んだ。それで私のポイント1は正しくないかもしれませんか？
回答:
ペイロード本体を含むメッセージを生成する送信者は、囲まれた表現の意図されたメディアタイプが送信者に知られていない限り、そのメッセージにContent-Typeヘッダーフィールドを生成する必要があります（SHOULD）。場合 Content-Typeヘッダフィールドが存在しない場合、受信者は、いずれかの「アプリケーション/オクテットストリーム」（のメディアタイプ仮定してもよい[RFC2046]、セクション4.5.1）、またはそのタイプを決定するために、データを調べ。
つまり、Content-TypeHTTPヘッダーはPUTとPOSTリクエストに対してのみ設定する必要があります。
Getリクエストにはリクエストエンティティ（つまり、本文）がないため、コンテンツタイプは必要ありません。
GETリクエストには、クライアントが理解するコンテンツのタイプを示す「Accept」ヘッダーを含めることができます。サーバーはそれを使用して、送信するコンテンツタイプを決定できます。
ただし、オプションです。
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1
受け入れられた答えは間違っています。引用は正しいですが、PUTとPOSTに必要であるという主張は正しくありません。PUTまたはPOSTが実際に追加のコンテンツを持っている必要はありません。GETが実際にコンテンツを持っていることの禁止もありません。
RFCはそれらが何を意味するかを正確に述べています.. IFFあなたの側（クライアントORオリジンサーバー）がHTTPヘッダーを超えて追加のコンテンツを送信する場合は、Content-Typeヘッダーを指定する必要があります。ただし、Content-Typeを省略しても、コンテンツを含めることができます（たとえば、Content-Lengthヘッダーを使用して）。
短い答え：ほとんどの場合、HTTP GETリクエストにcontent-typeヘッダーは必要ありません。しかし、仕様では、HTTP GETのコンテンツタイプヘッダーも除外されていないようです。
サポート資料：
「Content-Type」は、表現（つまり、ペイロード）メタデータの一部です。RFC 7231セクション3.1から引用 ：
3.1。表現メタデータ
表現ヘッダーフィールドは、表現に関するメタデータを提供します。メッセージにペイロード本体が含まれている場合、表現ヘッダーフィールドは、ペイロード本体で囲まれた表現データの解釈方法を記述します。...
次のヘッダーフィールドは、表現メタデータを伝達します。
+-------------------+-----------------+ | Header Field Name | Defined in... | +-------------------+-----------------+ | Content-Type | Section 3.1.1.5 | | ... | ... |
RFC 7231セクション3.1.1.5から引用（ちなみに、現在選択されている回答はセクション番号にタイプミスがありました）：
「Content-Type」ヘッダーフィールドは、関連付けられた表現のメディアタイプを示します
その意味で、Content-Typeヘッダーは実際にはHTTP GETリクエスト（またはPOSTまたはPUTリクエスト）に関するものではありません。それはそのようなどんなリクエストの中のペイロードについてでもあります。したがって、ペイロードがない場合、は必要ありませんContent-Type。実際には、一部の実装は先に進み、その理解可能な仮定を行いました。アダムのコメントから引用：
「仕様では、GETでContent-Typeを使用できないとは記載されていませんが、.NetはHttpClientでそれを強制しているようです。このSO q＆aを参照してください。」
ただし、厳密に言うと、仕様自体がHTTP GETにペイロードが含まれている可能性を排除するものではありません。RFC 7231セクション4.3.1から引用：
4.3.1 GET
...
GETリクエストメッセージ内のペイロードにはセマンティクスが定義されていません。GETリクエストでペイロードボディを送信すると、一部の既存の実装がリクエストを拒否する可能性があります。
したがって、何らかの理由でHTTP GETにペイロードが含まれているContent-Type場合は、ヘッダーもおそらく妥当です。
GETメッセージでcontent-typeを渡さないことの問題は、サーバー側がとにかくコンテンツを決定するため、content-typeが無関係であることを確認することです。私が遭遇した問題は、多くの場所で、Webサービスを十分にスマートに設定して、渡すコンテンツタイプを取得し、リクエストした「タイプ」で応答を返すようになっていることです。例えば。現在、デフォルトでJSONになっている場所でメッセージを送信していますが、webサービスが設定されているため、xmlのcontent-typeを渡すと、JSONのデフォルトではなくxmlが返されます。これは素晴らしいアイデアだと思います
SHOULD NOT。明示的な見積もりはありますか？