이 문장이 맞습니까? HTTP GET 메서드에는 항상 메시지 본문이 없습니다

Question

이 문이 맞습니까? HTTP GET 메서드에는 항상 메시지 본문이 없습니다. RFC2616에서 명시 적으로이 부분을 찾지 못했습니다.

그리고이 경우

는 HTTP GET 요청이 메시지 본문을 컬이하는이를 제외한

Answer 1

어느 restclient도 REST console 지원이 포함됩니다 어떤 상황에서 다음, 사실이 아니다. 요청 방법의 사양 (섹션 5.1.1) 요청에 엔티티 본문을 보내는 허용하지 않는 경우

HTTP specification

는 메시지 본문이 요청에 포함되어서는 안된다 4.3

절에서 말한다 .

Section 5.1.1은 다양한 방법으로 섹션 9.x로 리디렉션됩니다. 그들 중 누구도 명시 적으로 메시지 본문을 포함하는 것을 금지하지 않습니다. 그러나 ...

Section 5.2

는 인터넷 요청에 의해 확인

정확한 자원은 Request-URI 및 Host 헤더 필드 모두를 조사하여 결정했다.

및 Section 9.3는 GET 메소드는 요청-URI에 의해 식별된다 (엔터티의 형태로)간에 정보 취득 수단

말한다.

어느 함께 GET 요청을 처리 할 때, 서버가 다른 것을 검토 필요하지 것을 제안하는 요청-URI 및 호스트 헤더 필드.

요약하면 HTTP 사양은 GET을 사용하여 메시지 본문을 보내지 못하게하지 않지만 모든 서버에서 지원하지 않으면 놀랄만한 모호성이 있습니다.

Answer 2

나는 메시지 본문을 가진 GET 요청이 시험 분석기에 사용되는 elasticsearch이 건너 온 - https://www.elastic.co/guide/en/elasticsearch/guide/master/analysis-intro.html

기본적으로이 서버 측에서 아무 것도 변경하지 않는 요청입니다,하지만 긴 문자 메시지를 필요 입력으로 전달됩니다. 메시지 본문과 함께 GET 요청을 적절하게 사용하는 것처럼 보입니다.

Answer 3

이전 RFC2616이 대체되었으며 여러 RFC (7230-7237)로 대체되었습니다.

새로운 RFC 7230 on HTTP/1.1 명확하게 메시지 본문에 대해 말한다 :

하는 HTTP 메시지의 메시지 본문 (있는 경우) 해당 요청 또는 응답의
페이로드 본체를 수행하는 데 사용됩니다

. 섹션 3.3.1에서 설명한대로 전송 코딩이
으로 적용되지 않는 한 메시지 본문은 페이로드 본문과 동일한
입니다.

message-body = *OCTET 

메시지 본문은 메시지에 허용 될 때 규칙은 요청 및 응답을 을 다릅니다.

요청에서 메시지 본문의 존재 여부는
Content-Length 또는 Transfer-Encoding 헤더 필드로 알립니다. 요청 메시지
프레임 방법은 메시지 본문에 대한 용도를 정의하지 않고의 메서드 의미와 관계가 없습니다.
.

새로운 표준 분명히가 초기 질문에 답합니다. 그러나 GET 요청으로 메시지 본문을 무시할 수있는 오래된 소프트웨어가 있으므로 신중해야하며이 경우를 확인해야합니다.

Answer 4

나는 사양 당신이 메시지 본문을 추가 할 수 있습니다 생각 , 그래서 귀하의 질문에 대한 대답은 아니 (그러나주의와) 해야합니다.

하자 먼저 사양 (RFC 2616는 그들에 의해 폐기 된 다른 답변에서 언급 된 이후로는, RFC 7231, RFC 7232 및 RFC 7234에서 인용하고있다)를 확인.

From RFC 7230 :

The presence of a message body in a request is signaled by a 
Content-Length or Transfer-Encoding header field. Request message 
framing is independent of method semantics, even if the method does 
not define any use for a message body. 

참고 부품 "요청 방법의 명세서 (섹션 5.1.1)의로 entity를 전송하는 것을 허용하지 않으면 메시지 본문이 요청에 포함되지 않아야 요청에 몸을. " 이전 RFC 2616에있는이 제거되었습니다.

A payload within a GET request message has no defined semantics; 
sending a payload body on a GET request might cause some existing 
implementations to reject the request. 

그래서, 내 생각이, 당신은, GET 요청에 메시지 본문을 추가 할 수 있습니다 (이것은 원래의 질문에 대답한다)을 의미하지만 당신은해야 :

또한 7231 says this on the subject RFC 꼼꼼한. 사양에 언급 된 사례 만이 알고 있어야하는 것은 아니며 많은 도구, 클라이언트 및 서버가 단순히 메시지 본문을 기대하지 않고 오작동 할 수 있습니다. 예를 들어 Chrome에서는 XMLHttpRequest가 GET 용 메시지 본문을 삭제합니다.

또 다른 문제는 캐싱 중 하나입니다. RFC 7234에 따라.

The primary cache key consists of the request method and target URI 
[...] 
If a request target is subject to content negotiation, its cache 
entry might consist of multiple stored responses, each differentiated 
by a secondary key for the values of the original request's selecting 
header fields. 

이 다른 기관이지만 동일한 URL (및 선택 헤더)를 요청하고, 메시지 바디는 이전에 정확하게 서버로 전달 된 경우에도 캐시 동일한 응답을 갖는 것으로 간주된다는 것을 의미한다.결국

내가 가져 가능한 경우

• 하지 않는 한 당신은
• 당신은
• 당신은 잠재적 인 프록시 알고있는 서버를 제어하는 ​​클라이언트 캐시를 제어, 메시지 본문을 사용하지 않도록해야한다고 생각합니다 방해가 될 수 있습니다.
• 응답에서 캐싱을 사용하지 않도록 설정합니다 (실제로 캐싱 할 수 있도록 헤더를 사용할 수는 있지만 아이디어를 제대로 조사하지는 못했습니다).