요청 본문이있는 HTTP GET

우리 응용 프로그램을 위해 새로운 RESTful 웹 서비스를 개발 중입니다.

특정 엔티티에서 GET을 수행 할 때 클라이언트는 엔티티의 컨텐츠를 요청할 수 있습니다. 목록 정렬과 같은 일부 매개 변수를 추가하려는 경우 쿼리 문자열에 이러한 매개 변수를 추가 할 수 있습니다.

또는 사람들이 요청 본문에서 이러한 매개 변수를 지정할 수 있기를 바랍니다. HTTP / 1.1 은 이것을 명시 적으로 금지하지 않는 것 같습니다. 이를 통해 더 많은 정보를 지정할 수 있으며 복잡한 XML 요청을보다 쉽게 ​​지정할 수 있습니다.

내 질문 :

• 이것이 좋은 생각입니까?
• HTTP 클라이언트는 GET 요청 내에서 요청 본문 사용에 문제가 있습니까?

http://tools.ietf.org/html/rfc2616

GET 요청에 바디를 포함시키는 것에 대한 Roy Fielding의 의견 .

예. 다시 말해, 모든 HTTP 요청 메시지는 메시지 본문을 포함 할 수 있으므로이를 염두에두고 메시지를 구문 분석해야합니다. 그러나 GET에 대한 서버 시맨틱은 본문에 요청에 대한 시맨틱 의미가 없도록 제한됩니다. 구문 분석에 대한 요구 사항은 메소드 시맨틱에 대한 요구 사항과 별개입니다.

따라서 그렇습니다. GET을 사용하여 본문을 보낼 수 있으며, 그렇게하는 것은 결코 유용하지 않습니다.

이것은 사양이 분할되면 (작업 진행 중) 다시 명확 해 지도록 HTTP / 1.1의 계층화 된 디자인의 일부입니다.

.... 로이

예, GET을 사용하여 요청 본문을 보낼 수 있지만 의미가 없습니다. 서버에서 구문 분석 하고 내용에 따라 응답을 변경하여 의미를 부여 하면 HTTP / 1.1 스펙 4.3 절 에서이 권장 사항을 무시하는 것입니다 .

[...] 요청 방법 엔티티 바디에 대해 정의 된 의미를 포함하지 않는 경우, 메시지 본문 SHOULD 요청을 처리 할 때 무시된다.

HTTP / 1.1 스펙 섹션 9.3 에서 GET 메소드에 대한 설명은 다음과 같습니다.

GET 메소드는 Request-URI로 식별 된 모든 정보 ([...])를 검색하는 것을 의미합니다.

이것은 요청 본문이 GET 요청에서 자원 식별의 일부가 아니라 요청 URI만을 나타냅니다.

업데이트 "HTTP / 1.1 사양"으로 참조 된 RFC2616은 이제 더 이상 사용되지 않습니다. 2014 년에는 RFC 7230-7237로 대체되었습니다. "요청을 처리 할 때 메시지 본문을 무시해야합니다"라는 인용문이 삭제되었습니다. "메시지 본문에 대한 용도를 정의하지 않더라도 요청 메시지 프레임은 메소드 시맨틱과 무관합니다." 삭제되었습니다. -댓글에서

HTTP 사양에서 명시 적으로 배제하지 않는 한 그렇게 할 수 는 있지만 사람들이 그런 식으로 작동하지 않기 때문에 단순히 피하는 것이 좋습니다. HTTP 요청 체인에는 여러 단계가 있으며, HTTP 요청 체인은 "대부분"HTTP 사양을 준수하지만, 웹 브라우저에서 전통적으로 사용되는 것처럼 동작한다는 것뿐입니다. (투명한 프록시, 가속기, A / V 툴킷 등을 생각하고 있습니다.)

이것은 견고성 원칙의 배후에있는 대략적인 것입니다. "당신이 받아들이는 것에서 자유롭고, 당신이 보내는 것에서 보수적이어야합니다."

그러나 그럴만한 이유가 있다면 그렇게하십시오.

캐싱을 활용하려고하면 문제가 발생할 수 있습니다. 프록시는 매개 변수가 응답에 영향을 미치는지 확인하기 위해 GET 본문을 보지 않습니다.

어느 위해 RESTClient 이나 REST 콘솔은 이 기능을 지원하지만 컬을 수행합니다.

HTTP 사양은 4.3 절에 말한다

요청 방법 (5.1.1 절)의 명세가 엔티티 본문을 요청으로 전송하는 것을 허용하지 않는다면, 메시지 본문은 요청에 포함되어서는 안된다 (MUST NOT).

섹션 5.1.1 은 다양한 방법에 대해 섹션 9.x로 리디렉션합니다. 이들 중 어느 것도 메시지 본문의 포함을 명시 적으로 금지하지 않습니다. 하나...

섹션 5.2에 따르면

인터넷 요청으로 식별 된 정확한 리소스는 Request-URI와 Host header 필드를 모두 검사하여 결정됩니다.

및 9.3 절은 말한다

GET 메소드는 Request-URI에 의해 식별되는 모든 정보 (엔터티 형태)를 검색하는 것을 의미합니다.

GET 요청을 처리 할 때 서버는 Request-URI 및 Host 헤더 필드 이외의 다른 것을 검사 할 필요 가 없음을 함께 제안 합니다.

요약하면 HTTP 사양은 GET을 사용하여 메시지 본문을 보내지 못하게하지는 않지만 모든 서버에서 지원하지 않는 경우 놀라지 않을 정도로 모호합니다.

Elasticsearch는 본문이있는 GET 요청을 수락합니다. 이것이 바람직한 방법 인 것 같습니다. Elasticsearch 안내서

Ruby 드라이버와 같은 일부 클라이언트 라이브러리는 개발 모드에서 cry 명령을 stdout에 기록 할 수 있으며이 구문을 광범위하게 사용합니다.

달성하려는 것은 훨씬 일반적인 방법과 GET과 함께 페이로드를 사용하지 않는 방법으로 오랫동안 수행되었습니다.

특정 검색 미디어 유형을 구축하거나 더 RESTful하고 싶다면 OpenSearch와 같은 것을 사용하고 서버가 지시 한 URI에 요청을 POST하십시오 (예 : / search). 그런 다음 서버는 검색 결과를 생성하거나 최종 URI를 빌드하고 303을 사용하여 리디렉션 할 수 있습니다.

이것은 전통적인 PRG 방법을 따르는 장점이 있으며 캐시 중개인이 결과를 캐시하는 데 도움이됩니다.

즉, URI는 ASCII가 아닌 모든 항목에 대해 인코딩되므로 application / x-www-form-urlencoded 및 multipart / form-data입니다. ReSTful 시나리오를 지원하려는 경우 또 다른 사용자 정의 json 형식을 작성하는 대신 이것을 사용하는 것이 좋습니다.

몸과 함께 GET을 보내거나 POST를 보내고 RESTish religiosity를 포기할 수 있습니다.

훌륭한 결정도 아니지만 GET 본문을 전송하면 일부 클라이언트 및 일부 서버의 문제를 방지 할 수 있습니다.

POST를 수행하면 일부 RESTish 프레임 워크에 장애물이있을 수 있습니다.

Julian Reschke는 위의 "SEARCH"와 같은 비표준 HTTP 헤더를 사용하여 제안했을 때 지원할 가능성이 적다는 점을 제외하고는 훌륭한 해결책이 될 수 있다고 제안했습니다.

위의 각 작업을 수행 할 수 있고 수행 할 수없는 클라이언트를 나열하는 것이 가장 생산적 일 수 있습니다.

본문과 함께 GET을 보낼 수없는 고객 (내가 아는 것) :

• XmlHTTPRequest 피들러

본문과 함께 GET을 보낼 수있는 클라이언트 :

• 대부분의 브라우저

GET에서 본문을 검색 할 수있는 서버 및 라이브러리 :

• 아파치
• PHP

GET에서 본문을 제거하는 서버 (및 프록시) :

• ?

이 질문을 IETF HTTP WG에 넣었습니다. Roy Fielding (1998 년 http / 1.1 문서 저자)의 의견은

"... 수신되면 해당 본문을 구문 분석하고 삭제하는 것 이외의 다른 작업을 수행하기 위해 구현이 중단됩니다.

RFC 7213 (HTTPbis) 상태 :

"GET 요청 메시지 내의 페이로드에는 정의 된 의미가 없습니다."

의도는 GET 요청 본문에 의미 론적 의미가 금지되어 있기 때문에 요청 본문을 사용하여 결과에 영향을 줄 수 없음을 의미합니다.

GET에 본문을 포함하면 다양한 방법으로 요청을 확실히 중단 시키는 프록시가 있습니다 .

요약하면 그렇게하지 마십시오.

어느 서버가이를 무시합니까? – fijiaaron 8 월 30 일 12시 21 분 27 초

구글 예를 들어 그것을 무시보다 더하고있다, 그것은 그것에게 고려하게됩니다 오류 !

간단한 netcat으로 직접 시도해보십시오.

$ netcat www.google.com 80
GET / HTTP/1.1
Host: www.google.com
Content-length: 6

1234

(1234 내용 뒤에 CR-LF가옵니다. 총 6 바이트입니다)

그리고 당신은 얻을 것이다 :

HTTP/1.1 400 Bad Request
Server: GFE/2.0
(....)
Error 400 (Bad Request)
400. That’s an error.
Your client has issued a malformed or illegal request. That’s all we know.

또한 AkamaiGhost가 제공하는 Bing, Apple 등으로부터 400 건의 Bad Request를받습니다.

따라서 본문 엔터티와 함께 ​​GET 요청을 사용하지 않는 것이 좋습니다.

에서 RFC 2616, 섹션 4.3 , "메시지 본문"

서버는 요청시 메시지 본문을 읽고 전달해야합니다. 요청 방법에 엔티티 본문에 대해 정의 된 의미가 포함되어 있지 않으면 요청을 처리 할 때 메시지 본문을 무시해야합니다.

즉, 서버는 항상 네트워크에서 제공된 요청 본문을 읽어야합니다 (Content-Length 확인 또는 청크 본문 읽기 등). 또한 프록시는 그러한 요청 본문을 전달해야합니다. 그런 다음 RFC가 지정된 메소드의 본문에 대한 의미를 정의하면 서버는 실제로 요청 본문을 사용하여 응답을 생성 할 수 있습니다. 그러나 RFC 가 본문에 대한 의미를 정의 하지 않으면 서버는이를 무시해야합니다.

이것은 위의 Fielding의 인용문과 일치합니다.

9.3 절 . "GET"은 GET 메소드의 의미론을 설명하고 요청 본문은 언급하지 않습니다. 따라서 서버는 GET 요청에서 수신 한 요청 본문을 무시해야합니다.

XMLHttpRequest에 따르면 유효하지 않습니다. 로부터 표준 :

4.5.6 send()방법

client . send([body = null])

요청을 시작합니다. 선택적 인수는 요청 본문을 제공합니다. request 메소드가 GET또는 이면 인수가 무시됩니다 HEAD.

InvalidStateError상태가 열리지 않거나 send()플래그가 설정된 경우 예외를 발생 시킵니다.

방법은 다음 단계를 실행해야합니다 :send(body)

1. 상태가되지 않으면 열 , 던져 InvalidStateError예외.
2. 는 IF send()플래그가 설정되어, 던져 InvalidStateError예외.
3. 요청 메소드가 GET또는 인 HEAD경우 body 를 null로 설정하십시오 .
4. body 가 널인 경우 다음 단계로 이동하십시오.

그러나 GET 요청에 큰 본문 내용이 필요할 수 있기 때문에 그렇게 생각하지 않습니다.

따라서 브라우저의 XMLHttpRequest를 사용하면 작동하지 않을 수 있습니다.

캐싱 가능한 JSON / XML 본문을 웹 응용 프로그램으로 보내려면 데이터를 넣을 수있는 유일한 장소는 RFC4648로 인코딩 된 쿼리 문자열 ( URL 및 파일 이름 안전 알파벳을 사용한 Base 64 인코딩)입니다 . 물론 JSON을 urlencode하고 URL 매개 변수의 값에 넣을 수는 있지만 Base64는 더 작은 결과를 제공합니다. URL 크기 제한 이 있습니다. 다른 브라우저에서 URL의 최대 길이는 얼마입니까?를 참조하십시오 . .

Base64의 패딩 =문자가 URL의 매개 변수 값에 좋지 않을 수 있다고 생각할 수도 있지만 http://mail.python.org/pipermail/python-bugs-list/2007-February/037195.html 토론을 참조 하십시오 . 그러나 패딩이있는 인코딩 된 문자열은 값이 비어있는 매개 변수 키로 해석되므로 param 이름없이 인코딩 된 데이터를 넣지 마십시오. 나는 같은 것을 사용할 것이다 ?_b64=<encodeddata>.

나는 이것을 권고하지 않을 것이며, 그것은 표준 관행에 위배되며 그 대가로 그다지 많은 것을 제공하지 않습니다. 옵션이 아닌 컨텐츠를 위해 본문을 유지하려고합니다.

부적합한 base64로 인코딩 된 헤더는 어떻습니까? "SOMETHINGAPP-PARAMS : sdfSD45fdg45 / aS"

길이 제한 hm. POST 처리가 의미를 구별하도록 할 수 없습니까? 정렬과 같은 간단한 매개 변수를 원한다면 이것이 왜 문제가되는지 모르겠습니다. 당신이 걱정하는 것이 확실합니다.

프로토콜이 OOP를 지원하지 않으므로 REST가 화가 났으며 Get방법은 증거입니다. 솔루션으로 DTO를 JSON으로 직렬화 한 다음 쿼리 문자열을 만들 수 있습니다. 서버 측에서는 쿼리 문자열을 DTO에 직렬화 해제 할 수 있습니다.

살펴보십시오 :

• ServiceStack의 메시지 기반 디자인
• WCF로 RESTful 메시지 기반 웹 서비스 구축

메시지 기반 접근 방식을 사용하면 Get 메소드 제한 사항을 해결할 수 있습니다. 요청 본문과 마찬가지로 모든 DTO를 보낼 수 있습니다

Nelibur 웹 서비스 프레임 워크는 사용할 수있는 기능을 제공합니다

var client = new JsonServiceClient(Settings.Default.ServiceAddress);
var request = new GetClientRequest
    {
        Id = new Guid("2217239b0e-b35b-4d32-95c7-5db43e2bd573")
    };
var response = client.Get<GetClientRequest, ClientResponse>(request);

as you can see, the GetClientRequest was encoded to the following query string

http://localhost/clients/GetWithResponse?type=GetClientRequest&data=%7B%22Id%22:%2217239b0e-b35b-4d32-95c7-5db43e2bd573%22%7D

예를 들어 Curl, Apache 및 PHP에서 작동합니다.

PHP 파일 :

<?php
echo $_SERVER['REQUEST_METHOD'] . PHP_EOL;
echo file_get_contents('php://input') . PHP_EOL;

콘솔 명령 :

$ curl -X GET -H "Content-Type: application/json" -d '{"the": "body"}' 'http://localhost/test/get.php'

산출:

GET
{"the": "body"}

IMHO는 JSON인코딩 된 (즉 , encodeURIComponent)을 사양을 URL위반하지 않고 서버로 HTTP가져올 수 있는 방식으로 보낼 수 있습니다 JSON.

GET과 함께 요청 본문을 사용하는 것보다 훨씬 나은 옵션 목록이 있습니다.

각 범주에 대한 범주와 항목이 있다고 가정 해 봅시다. 둘 다 id로 식별됩니다 (이 예에서는 "catid"/ "itemid"). 특정 "순서"에서 다른 매개 변수 "sortby"에 따라 정렬하려고합니다. "정렬"및 "순서"에 대한 매개 변수를 전달하려고합니다.

당신은 할 수 있습니다 :

1. 쿼리 문자열 사용 example.com/category/{catid}/item/{itemid}?sortby=itemname&order=asc
2. 경로에 mod_rewrite (또는 이와 유사한)를 사용하십시오. example.com/category/{catid}/item/{itemid}/{sortby}/{order}
3. 요청과 함께 전달한 개별 HTTP 헤더를 사용하십시오.
4. POST와 같은 다른 방법을 사용하여 리소스를 검색하십시오.

모두 단점이 있지만 몸에 GET을 사용하는 것보다 훨씬 낫습니다.

이 페이지에서 자주 인용되는 것처럼 인기있는 도구가 이것을 사용하더라도 사양에 의해 금지되지는 않지만 너무 이국적이라는 것은 여전히 ​​나쁜 생각이라고 생각합니다.

많은 중간 인프라가 그러한 요청을 거부 할 수 있습니다.

예를 들어으로이 같은 웹 사이트의 앞에 가능한 CDN의 일부를 사용하여 잊어 일 :

뷰어 GET요청에 본문이 포함 된 경우 CloudFront는 HTTP 상태 코드 403 (Forbidden)을 뷰어에 반환합니다.

그리고 네, 귀하의 클라이언트 라이브러리는이 의견에 보고 된 바와 같이 그러한 요청의 방출을 지원하지 않을 수도 있습니다 .

클라이언트 프로그램에서 Spring 프레임 워크의 RestTemplate을 사용하고 있으며 서버 측에서 Json 본문으로 GET 요청을 정의했습니다. 내 주요 목적은 당신과 동일합니다 : 요청에 많은 매개 변수가있을 때 본문에 넣는 것이 연장 된 URI 문자열에 넣는 것보다 더 깔끔한 것처럼 보입니다. 예?

그러나 슬프게도 작동하지 않습니다! 서버 측에서 다음 예외가 발생했습니다.

org.springframework.http.converter.HttpMessageNotReadableException : 필요한 요청 본문이 없습니다 ...

그러나 클라이언트 코드가 메시지 본문을 올바르게 제공한다고 확신하므로 무엇이 잘못 되었습니까?

RestTemplate.exchange () 메소드를 추적하여 다음을 발견했습니다.

// SimpleClientHttpRequestFactory.class
public class SimpleClientHttpRequestFactory implements ClientHttpRequestFactory, AsyncClientHttpRequestFactory {
    ...
    protected void prepareConnection(HttpURLConnection connection, String httpMethod) throws IOException {
        ...
        if (!"POST".equals(httpMethod) && !"PUT".equals(httpMethod) && !"PATCH".equals(httpMethod) && !"DELETE".equals(httpMethod)) {
            connection.setDoOutput(false);
        } else {
            connection.setDoOutput(true);
        }
        ...
    }
}

// SimpleBufferingClientHttpRequest.class
final class SimpleBufferingClientHttpRequest extends AbstractBufferingClientHttpRequest {
    ...
    protected ClientHttpResponse executeInternal(HttpHeaders headers, byte[] bufferedOutput) throws IOException {
        ...
        if (this.connection.getDoOutput() && this.outputStreaming) {
            this.connection.setFixedLengthStreamingMode(bufferedOutput.length);
        }

        this.connection.connect();
        if (this.connection.getDoOutput()) {
            FileCopyUtils.copy(bufferedOutput, this.connection.getOutputStream());
        } else {
            this.connection.getResponseCode();
        }
        ...
    }
}

executeInternal () 메소드에서 입력 인수 'bufferedOutput'에는 내 코드에서 제공하는 메시지 본문이 포함되어 있습니다. 나는 디버거를 통해 그것을 보았다.

그러나 prepareConnection ()으로 인해 executeInternal ()의 getDoOutput ()은 항상 false를 리턴하여 bufferedOutput을 완전히 무시합니다. 출력 스트림에 복사되지 않습니다.

결과적으로 서버 프로그램이 메시지 본문을 수신하지 못하고 예외를 던졌습니다.

이것은 Spring 프레임 워크의 RestTemplate에 대한 예제입니다. 요점은 메시지 본문이 더 이상 HTTP 스펙에 의해 금지되지 않더라도 일부 클라이언트 또는 서버 라이브러리 또는 프레임 워크는 여전히 이전 스펙을 준수하고 GET 요청에서 메시지 본문을 거부 할 수 있다는 것입니다.