HTTP GET 요청에 컨텐츠 유형 헤더가 필요합니까?
내가 이해하는 한 콘텐츠 유형을 설정하는 두 가지 장소가 있습니다.
- 클라이언트는 서버로 전송하는 본문 (예 : 게시)의 컨텐츠 유형을 설정합니다.
- 서버는 응답의 컨텐츠 유형을 설정합니다.
이것은 모든 가져 오기 요청 (클라이언트 측)에 대해 콘텐츠 유형을 설정할 필요가 없거나 설정하지 않아야 함을 의미합니다. 그리고 어떤 콘텐츠 유형이 될 수 있습니까?
또한 클라이언트의 컨텐츠 유형이 클라이언트가 수신하려는 컨텐츠 유형을 지정한다는 게시물을 몇 개 읽었습니다. 어쩌면 내 포인트 1이 맞지 않을까요?
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 귀하의 측 (클라이언트 OR 오리진 서버)은 HTTP 헤더를 넘어서 추가 컨텐츠를 전송할 것이므로 컨텐츠 유형 헤더를 지정해야합니다. 그러나 Content-Type을 생략하고 여전히 Content를 포함 할 수 있습니다 (예 : Content-Length 헤더 사용).
GET 메시지에서 컨텐츠 유형을 전달하지 않는 문제는 서버 측에서 컨텐츠를 결정하기 때문에 컨텐츠 유형이 관련이 없다는 것입니다. 내가 겪은 문제는 이제 전달하는 콘텐츠 유형을 선택하고 요청한 '유형'으로 응답을 반환하기에 충분히 스마트하도록 웹 서비스를 설정하는 많은 장소가 있다는 것입니다. 예 : 우리는 현재 기본값이 JSON 인 장소와 메시지를 보내고 있지만 xml의 콘텐츠 유형을 전달하면 JSON 기본값이 아닌 xml을 반환하도록 웹 서비스를 설정했습니다. 앞으로 나아가는 것이 좋은 생각이라고 생각합니다
참고 URL : https://stackoverflow.com/questions/5661596/do-i-need-a-content-type-header-for-http-get-requests
'IT' 카테고리의 다른 글
| 다른 제품 맛에 대해 서로 다른 종속성을 정의하는 방법 (0) | 2020.06.27 |
|---|---|
| numpy 배열의 파이썬 메모리 사용 (0) | 2020.06.27 |
| __file__ 변수는 무엇을 의미합니까? (0) | 2020.06.27 |
| 스칼라 : 한 문장으로 파일에 문자열 쓰기 (0) | 2020.06.26 |
| 경고-빌드 경로는 실행 환경을 지정합니다. J2SE-1.4 (0) | 2020.06.26 |