답변:
RFC 7231 섹션 3.1.5.5 에 따르면 :
페이로드 본문을 포함하는 메시지를 생성하는 발신인 은 동봉 된 표현의 의도 된 미디어 유형이 발신인에게 알려지지 않은 경우 해당 메시지에 Content-Type 헤더 필드 를 생성해야합니다 ( SHOULD) . 경우에 하는 Content-Type 헤더 필드가 존재하지 않는받는 사람 중 하나 "응용 프로그램 / octet-stream을"(의 미디어 유형 가정 할 수있다 [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 옆 (클라이언트 또는 원 서버) HTTP 헤더를 넘어, 그것은 Content-Type 헤더를 지정해야합니다, 추가 콘텐츠를 전송됩니다. 그러나 Content-Type을 생략해도 여전히 Content를 포함 할 수 있습니다 (예 : Content-Length 헤더 사용).
짧은 대답 : 대부분 HTTP GET 요청에 컨텐츠 유형 헤더 가 필요하지 않습니다 . 그러나 스펙은 HTTP GET에 대한 컨텐츠 유형 헤더를 배제하지 않는 것 같습니다.
지원 자료 :
"컨텐츠 유형"은 표현 (즉, 페이로드) 메타 데이터의 일부입니다. 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헤더는 실제로 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헤더도 합리적입니다.
SHOULD NOT콘텐츠 타입을 포함한다. 명시적인 인용문이 있습니까?