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

http://example.com/page ? parameter = value & also = another

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

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

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

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

parameter=value&also=another

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

내용은 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 요청 및 응답 페이로드가 회선을 통해 전송되는 것을 보는 데 사용할 수 있습니다.

짧은 답변 : POST 요청에서 값은 요청의 "본문"으로 전송됩니다. 웹 양식을 사용하면 미디어 유형이 application/x-www-form-urlencoded또는로 전송 될 가능성이 높습니다 multipart/form-data. 언어 또는 일반적으로 요청 "옳은 일을 ™"할과 (같은 쉽게 쉽게 디코딩 값에 대한 액세스를 제공 핸들 웹 요청에 디자인 된 프레임 워크 프로그래밍 $_REQUEST또는 $_POSTPHP에서, 또는 cgi.FieldStorage(), flask.request.form파이썬을).

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

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

GET ( 관련 RFC 섹션 )

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

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

키와 값은 URI의 일부입니다. 브라우저 는 URI 길이에 제한을 둘 수 있습니다 . HTTP 표준은 제한이 없다고 명시하고 있습니다. 그러나이 글을 쓰는 시점에서 대부분의 브라우저 는 URI를 제한합니다 (특정한 값은 없습니다). 서버에 새로운 정보를 제출하는 데 GET요청을 사용해서는 안됩니다 . 특히 더 큰 문서는 아닙니다. 당신이 사용해야하는 곳이다 POST나 PUT.

POST ( 관련 RFC 섹션 )

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

POST좀 더 복잡한 (및 인 방법 보다 유연)

POST 요청을 수신 할 때는 항상 "페이로드"또는 HTTP 용어 인 메시지 본문을 기대해야합니다 . 메시지 본문 자체에는 표준 이 없기 때문에 꽤 쓸모가 없습니다 (어쩌면 응용 프로그램 / octet-stream?). 본문 형식은 Content-Type헤더 로 정의됩니다 . FORM와 함께 HTML 요소를 사용할 때 method="POST"일반적으로 application/x-www-form-urlencoded입니다. 또 다른 매우 일반적인 유형은파일 업로드를 사용 하는 경우 multipart / form-data 입니다. 그러나 이것은 무엇이든text/plain , 이상 application/json또는 심지어 관습에 이르기까지 다양 할 수 있습니다 application/octet-stream.

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

대부분의 프로그래밍 언어 (및 / 또는 웹 프레임 워크)는 메시지 본문을 가장 일반적인 유형 (예 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, 및과 정확히 콘텐츠. 그 이상도 이하도 아닌. 아이디어는 클라이언트 가 "퍼팅"하기 전에 전체 리소스를 만들어야 할 책임 이 있다는 것입니다. 서버는 주어진 URL에서 그대로 받아 들여야합니다 .

결과적으로 POST요청은 일반적으로 기존 자원 을 대체 하는 데 사용되지 않습니다 . PUT요청은 할 모두 만들 수 있습니다 및 교체합니다.

사이드 노트

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

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

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

예를 들어 Live 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

포스트 값이됩니다.

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

예를 들면 다음과 같습니다.

Name: John Smith
Grade: 19

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

Name=John+Smith&Grade=19

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

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

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

일부 웹 서비스에서는 요청 데이터 및 메타 데이터 를 배치해야합니다. 별도로 . 예를 들어, 원격 기능은 서명 된 메타 데이터 문자열이 URI에 포함되는 반면 데이터는 HTTP- 본체에 게시 될 것으로 예상 할 수 있습니다.

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

이 접근 방식은 단일을 사용하여 QueryString과 Body-Post를 논리적으로 결합합니다. Content-Type 은 웹 서버에 대한 "구문 분석"인 을 합니다.

참고 : HTTP / 1.1은 왼쪽 의 (공백)과 오른쪽의 (줄 바꿈)으로 래핑 됩니다 .#32#10

우선, GET와POST

가져 오기 : 그것은 기본입니다 HTTP서버에 만들어지고 다음에 오는 서버와 쿼리 문자열에서 데이터를 검색하는 데 사용됩니다 요청 ?A는에서 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

왜 POST를 통해 POST해야합니까?

에서 GET일반적으로 쿼리 문자열의 기본 URL에 추가 된 서버로 전송되는 값, 지금의이 개 결과가있다

• GET요청은 매개 변수를 사용하여 브라우저 기록에 저장됩니다. 따라서 브라우저 기록에서 비밀번호는 암호화되지 않은 상태로 유지됩니다. 이것은 며칠 전 페이스 북에게있어 실질적인 문제였습니다.
• 일반적으로 서버는 사용 가능한 기간에 제한 URI이 있습니다. 너무 많은 매개 변수가 전송되면414 Error - URI too long

게시 요청의 경우 필드의 데이터가 대신 본문에 추가됩니다. 요청 매개 변수의 길이가 계산되어 컨텐츠 길이의 헤더에 추가되며 중요한 데이터가 URL에 직접 추가되지 않습니다.

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

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