[http] HTTP GET 요청에 컨텐츠 유형 헤더가 필요합니까?

Program / 글쓴이

내가 이해하는 한 콘텐츠 유형을 설정하는 두 가지 장소가 있습니다.

  1. 클라이언트는 서버로 전송하는 본문 (예 : 게시)의 컨텐츠 유형을 설정합니다.
  2. 서버는 응답의 컨텐츠 유형을 설정합니다.

이것은 모든 가져 오기 요청 (클라이언트 측)에 대해 컨텐츠 유형을 설정할 필요가 없거나 설정하지 않아야 함을 의미합니다. 그리고 어떤 콘텐츠 유형이 될 수 있습니까?

또한 클라이언트의 컨텐츠 유형이 클라이언트가 수신하려는 컨텐츠 유형을 지정한다는 게시물을 몇 개 읽었습니다. 어쩌면 내 포인트 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 옆 (클라이언트 또는 원 서버) HTTP 헤더를 넘어, 그것은 Content-Type 헤더를 지정해야합니다, 추가 콘텐츠를 전송됩니다. 그러나 Content-Type을 생략해도 여전히 Content를 포함 할 수 있습니다 (예 : Content-Length 헤더 사용).

답변

짧은 대답 : 대부분 HTTP GET 요청에 컨텐츠 유형 헤더 가 필요하지 않습니다 . 그러나 스펙은 HTTP GET에 대한 컨텐츠 유형 헤더를 배제하지 않는 것 같습니다.

지원 자료 :

  1. “컨텐츠 유형”은 표현 (즉, 페이로드) 메타 데이터의 일부입니다. RFC 7231 섹션 3.1 에서 인용
    :

    3.1. 표현 메타 데이터

    표현 헤더 필드는 표현에 대한 메타 데이터를 제공합니다. 메시지에 페이로드 본문이 포함 된 경우 표현 헤더 필드는 페이로드 본문에 포함 된 표현 데이터를 해석하는 방법을 설명합니다. …

    다음 헤더 필드는 표현 메타 데이터를 전달합니다.

    +-------------------+-----------------+
| Header Field Name | Defined in...   |
+-------------------+-----------------+
| Content-Type      | Section 3.1.1.5 |
| ...               | ...             |

    RFC 7231 섹션 3.1.1.5 에서 인용했습니다 (현재 선택된 답변은 섹션 번호에 오타가 있음).

    “컨텐츠 유형”헤더 필드는 연관된 표현의 미디어 유형을 나타냅니다.

  2. 그런 의미에서 Content-Type헤더는 실제로 HTTP GET 요청 (또는 그 문제에 대한 POST 또는 PUT 요청)이 아닙니다. 이 같은 내부의 페이로드에 관한 어떤 요청합니다. 따라서 페이로드가 없으면 필요하지 않습니다 Content-Type. 실제로 일부 구현이 진행되어 이해할 수있는 가정이되었습니다. 아담의 의견 에서 인용 :

    “… 스펙은 GET에 Content-Type을 가질 수 없다고 말하지 않지만, .Net은 HttpClient에서이를 강제하는 것 같습니다. 이 SO q & a를보십시오 .”

  3. 그러나 엄격하게 말하면 사양 자체는 HTTP GET에 페이로드가 포함될 가능성을 배제하지 않습니다. RFC 7231 섹션 4.3.1 에서 인용 :

    4.3.1 GET

    …

    GET 요청 메시지 내의 페이로드에는 정의 된 의미가 없습니다. GET 요청에서 페이로드 본문을 전송하면 일부 기존 구현에서 요청을 거부 할 수 있습니다.

    따라서 HTTP GET이 어떤 이유로 든 페이로드를 포함하면 Content-Type헤더도 합리적입니다.

답변

GET 메시지에서 컨텐츠 유형을 전달하지 않는 문제는 서버 측에서 컨텐츠를 결정하기 때문에 컨텐츠 유형이 관련이 없다는 것입니다. 내가 겪은 문제는 이제 전달하는 콘텐츠 유형을 선택하고 요청한 ‘유형’으로 응답을 반환하기에 충분히 스마트하도록 웹 서비스를 설정하는 많은 장소가 있다는 것입니다. 예 : 우리는 현재 기본값이 JSON 인 장소와 메시지를 보내고 있지만 웹 서비스를 설정하여 콘텐츠 유형의 xml을 전달하면 JSON 기본값이 아닌 xml을 반환합니다. 앞으로 나아가는 것이 좋은 생각이라고 생각합니다

답변