IT-Swarm.Net

매개 변수는 HTTP에서 어떻게 보내 집니까? POST 의뢰?

HTTPGET요청에서 매개 변수는 쿼리 문자열 로 전송됩니다.

http://example.com/page? 매개 변수 = 값 & 또한 = 다른

HTTPPOST요청에서 매개 변수는 URI와 함께 전송되지 않습니다.

값은 어디에 있습니까? 요청 헤더에? 요청 본문에? 그것은 어떻게 생겼습니까?

1314
Camilo Martin

값은 요청 본문에서 콘텐츠 유형이 지정하는 형식으로 전송됩니다.

일반적으로 콘텐츠 형식은 application/x-www-form-urlencoded이므로 요청 본문은 쿼리 문자열과 동일한 형식을 사용합니다.

parameter=value&also=another

양식에서 파일 업로드를 사용하는 경우 형식이 다른 multipart/form-data 인코딩을 대신 사용합니다. 더 복잡하지만 일반적으로 어떻게 보이는지 신경 쓸 필요가 없으므로 예제를 보여주지는 않겠지 만 그것이 존재한다는 것을 아는 것이 좋을 수 있습니다.

1109
Guffa

내용은 HTTP 헤더 뒤에 놓입니다. HTTP POST 형식은 HTTP 헤더와 빈 줄, 요청 본문 순으로 구성됩니다. POST 변수는 키 - 값 쌍으로 본문에 저장됩니다.

아래와 같이 HTTP Post의 원시 컨텐츠에서이를 볼 수 있습니다.

POST /path/script.cgi HTTP/1.0
From: frog@jmarshall.com
User-Agent: HTTPTool/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 32

home=Cosby&favorite+flavor=flies

Fiddler 와 같은 도구를 사용하면이를 볼 수 있습니다.이 도구를 사용하면 원시 HTTP 요청 및 응답 페이로드가 전선을 통해 전송되는 것을 볼 수 있습니다.

397
Joe Alfano

짧은 답변 : POST 요청에서, 요청의 "본문"에 값이 전송됩니다. 웹 양식을 사용하면 미디어 유형이 application/x-www-form-urlencoded 또는 multipart/form-data로 전송 될 가능성이 높습니다. 웹 요청을 처리하도록 설계된 프로그래밍 언어 또는 프레임 워크는 일반적으로 이러한 요청으로 "The Right Thing ™"을 수행하며 PHP의 $_REQUEST 또는 $_POST와 같이 쉽게 디코딩 된 값에 쉽게 액세스 할 수 있습니다. , 또는 cgi.FieldStorage(), flask.request.form Python).


이제 차이를 이해하는 데 도움이 될 수있는 약간의 digress를 해봅시다;)

GETPOST 요청의 차이점은 크게 의미가 있습니다. 그것들은 또한 다르게 "사용"되며, 이는 값이 전달되는 방식의 차이를 설명합니다.

GET ( 관련 RFC 섹션 )

GET 요청을 실행할 때 서버에 하나 또는 일련의 엔티티를 요청합니다. 클라이언트가 결과를 필터링 할 수 있도록 URL의 "쿼리 문자열"을 사용할 수 있습니다. 쿼리 문자열은 ? 다음 부분입니다. 이것은 RI 구문 의 일부입니다.

따라서 애플리케이션 코드의 관점 ( receives 요청 부분)에서 이러한 값에 액세스하려면 URI 쿼리 부분을 검사해야합니다.

키와 값은 URI의 일부입니다. 브라우저 may URI 길이에 제한을 둡니다. HTTP 표준은 제한이 없다고 명시하고 있습니다. 그러나이 글을 쓰는 시점에서 대부분의 브라우저 do URI를 제한합니다 (구체적인 값은 없습니다). GET 요청은 never 서버에 새 정보를 제출하는 데 사용해야합니다. 특히 더 큰 문서는 아닙니다. 여기서 POST 또는 PUT을 사용해야합니다.

POST ( 관련 RFC 섹션 )

POST 요청을 실행할 때 클라이언트는 실제로 새로운 document 를 원격 호스트에 제출합니다. 따라서 query 문자열은 (의미 적으로) 의미가 없습니다. 애플리케이션 코드에서 액세스 할 수없는 이유가 여기에 있습니다.

POST은 조금 더 복잡합니다 (그리고 way 더 유연합니다) :

POST 요청을 수신 할 때는 항상 "페이로드"또는 HTTP 용어로 message body 를 예상해야합니다. 메시지 본문 자체는 standard (내가 말할 수있는 한 응용 프로그램/옥텟 스트림?) 형식이 없으므로 쓸모가 없습니다. 본문 형식은 Content-Type 헤더로 정의됩니다. method="POST"와 함께 HTML FORM 요소를 사용하는 경우 일반적으로 application/x-www-form-urlencoded입니다. 또 다른 매우 일반적인 유형은 파일 업로드를 사용하는 경우 multipart/form-data 입니다. 그러나 text/plain, application/json 또는 사용자 지정 application/octet-stream에 이르는 anything 일 수 있습니다.

어쨌든 응용 프로그램에서 처리 할 수없는 Content-TypePOST 요청을하면 415 status-code 를 반환해야합니다.

대부분의 프로그래밍 언어 (및/또는 웹 프레임 워크)는 가장 일반적인 유형 (application/x-www-form-urlencoded, multipart/form-data 또는 application/json)과 같이 메시지 본문을 해독/인코딩하는 방법을 제공합니다. 그래서 쉽습니다. 사용자 정의 유형은 잠재적으로 약간 더 많은 작업이 필요합니다.

표준 HTML 양식으로 인코딩 된 문서를 예로 사용하면 응용 프로그램은 다음 단계를 수행해야합니다.

  1. Content-Type 필드를 읽으십시오
  2. 값이 지원되는 미디어 유형 중 하나가 아닌 경우 415 상태 코드로 응답을 반환하십시오.
  3. 그렇지 않으면 메시지 본문에서 값을 디코딩하십시오.

다시 말하지만, PHP와 같은 언어 나 다른 인기있는 언어의 웹 프레임 워크가이를 처리 할 것입니다. 이에 대한 예외는 415 오류입니다. 어떤 프레임 워크도 애플리케이션이 지원하거나 지원하지 않는 컨텐츠 유형을 예측할 수 없습니다. 이것은 당신에게 달려 있습니다.

PUT ( 관련 RFC 섹션 )

PUT 요청은 POST 요청과 정확히 같은 방식으로 처리됩니다. 가장 큰 차이점은 POST 요청이 서버가 새 리소스를 생성하는 방법을 결정하게한다는 것입니다. 역사적으로 (현재는 사용되지 않는 RFC2616부터 요청이 전송 된 URI의 "하위"(하위)로서 새로운 자원을 작성하는 것이 었습니다).

대조적으로 PUT 요청은 해당 URI를 정확히 at 자원으로 "예치"하고 exactly 함유량. 그 이상도 이하도 아닌. 아이디어는 client 가 "PUTting"전에 complete 리소스를 만들 책임이 있다는 것입니다. 서버는 주어진 URL에서 as-is 을 수락해야합니다.

결과적으로 POST 요청은 일반적으로 기존 자원을 replace 하는 데 사용되지 않습니다. PUT 요청은 create and replace를 모두 수행 할 수 있습니다.

사이드 노트

" 경로 매개 변수 "도 추가되어 원격으로 추가 데이터를 보내는 데 사용할 수 있지만 너무 드물기 때문에 여기서 자세히 설명하지 않습니다. 그러나 참고로 RFC에서 발췌 한 내용은 다음과 같습니다.

계층 적 경로의 도트 세그먼트 외에도 경로 세그먼트는 일반 구문에 의해 불투명 한 것으로 간주됩니다. URI 생성 응용 프로그램은 종종 세그먼트에 허용 된 예약 문자를 사용하여 체계 별 또는 역 참조 처리기 별 하위 구성 요소를 구분합니다. 예를 들어 세미콜론 ( ";")과 같음 ( "=") 예약 문자는 종종 해당 세그먼트에 적용 가능한 매개 변수와 매개 변수 값을 구분하는 데 사용됩니다. 쉼표 ( ",") 예약 문자는 종종 유사한 목적으로 사용됩니다. 예를 들어, 하나의 URI 생성자는 "name"의 버전 1.1에 대한 참조를 나타 내기 위해 "name; v = 1.1"과 같은 세그먼트를 사용할 수있는 반면, 다른 하나는 "name, 1.1"과 같은 세그먼트를 사용하여 동일한 것을 나타낼 수 있습니다. 매개 변수 유형은 스킴 별 의미론으로 정의 될 수 있지만 대부분의 경우 매개 변수 구문은 URI 역 참조 알고리즘의 구현에 따라 다릅니다.

344
exhuma

브라우저 URL 표시 줄에 직접 입력 할 수 없습니다.

라이브 HTTP 헤더 예를 들어 POST 데이터가 인터넷에서 어떻게 전송되는지 볼 수 있습니다. 결과는 다음과 같습니다.

http://127.0.0.1/pass.php
POST /pass.php HTTP/1.1

Host: 127.0.0.1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Referer: http://127.0.0.1/pass.php
Cookie: passx=87e8af376bc9d9bfec2c7c0193e6af70; PHPSESSID=l9hk7mfh0ppqecg8gialak6gt5
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
username=zurfyx&pass=password

그것이 말하는 곳

Content-Length: 30
    username=zurfyx&pass=password

게시물 값이됩니다.

54
zurfyx

POST 요청의 기본 미디어 유형은 application/x-www-form-urlencoded입니다. 이것은 키 - 값 쌍을 인코딩하기위한 형식입니다. 키는 중복 될 수 있습니다. 각 키 - 값 쌍은 & 문자로 구분되며 각 키는 = 문자로 값과 구분됩니다.

예 :

Name: John Smith
Grade: 19

다음과 같이 인코딩됩니다.

Name=John+Smith&Grade=19

이것은 HTTP 헤더 뒤에 요청 본문에 배치됩니다.

20
Nejat

일부 웹 서비스에서는 datametadata를 별도로 요청해야합니다. 예를 들어 원격 함수는 데이터가 HTTP 본문에 게시되는 동안 서명 된 메타 데이터 문자열이 URI에 포함될 것으로 예상 할 수 있습니다.

POST 요청은 의미 론적으로 다음과 같이 보일 수 있습니다 :

POST /?AuthId=YOURKEY&Action=WebServiceAction&Signature=rcLXfkPldrYm04 HTTP/1.1
Content-Type: text/tab-separated-values; charset=iso-8859-1
Content-Length: []
Host: webservices.domain.com
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: identity
User-Agent: Mozilla/3.0 (compatible; Indy Library)

name    id
John    G12N
Sarah   J87M
Bob     N33Y

이 접근법은 논리적으로 웹 서버의 "구문 분석 명령"인 단일 Content-Type를 사용하여 QueryString과 Body-Post를 결합합니다.

참고 : HTTP/1.1은 왼쪽에 #32 (공백) 및 오른쪽에 #10 (줄 바꿈)가있는 줄 바꿈입니다.

17
Interface Unknown

HTTP POST의 양식 값은 요청 본문에서 쿼리 문자열과 동일한 형식으로 전송됩니다.

자세한 내용은 spec 을 참조하십시오.

13
SLaks

우선, GETPOST을 구분 해 봅시다.

Get : 서버에 대한 기본 HTTP 요청이며 서버에서 데이터를 검색하는 데 사용되며 URI에서 ? 이후에 오는 쿼리 문자열은 고유 한 리소스를 검색하는 데 사용됩니다.

이것은 형식입니다.

GET /someweb.asp?data=value HTTP/1.0

여기에 data=value는 전달 된 쿼리 문자열 값입니다.

POST : 서버에 안전하게 데이터를 보내는 데 사용되므로 필요한 모든 것이 POST 요청의 형식입니다

POST /somweb.aspHTTP/1.0
Host: localhost
Content-Type: application/x-www-form-urlencoded //you can put any format here
Content-Length: 11 //it depends
Name= somename

GET을 통해 POST 이유는 무엇입니까?

GET에서 서버에 보내는 값은 일반적으로 쿼리 문자열의 기본 URL에 추가됩니다. 이렇게하면 데이터가 해킹 당할 수 있습니다 (자격 증명이 노출 된 Facebook의 문제 일). 이것이 POSTRequest Body를 사용하여 서버에 데이터를 보내려면 데이터를 숨기고 서버의 데이터를 숨기고 데이터를 필드에서 가져오고 길이를 계산하여 headercontent-length 및 중요하지 않은 서버에 추가하십시오 데이터는 URL에 직접 추가됩니다.

요청이 안전하게 처리되었으므로 서버에 보내는 값을 Request Body로 보낼 수 있습니다. 이름에서 알 수 있듯이 사용자가 보내려는 데이터가 포함되어 있습니다 (URL Encoded 형식으로 전송됩니다). Request Headers는 요청을 보관합니다 Request Body의 값과 Request Headers를 비교하여 보안을 유지합니다.

Google 개발자 도구의 네트워크 섹션을 사용하여 서버에 요청하는 방법에 대한 기본 정보를 볼 수 있습니다.

Request Headers, Origin, Accept과 같은 Cache-Control에 항상 더 많은 값을 추가 할 수 있습니다.

3
Zeeshan Adil