게시 요청과 요청 받기의 차이점을 구문 분석합니다.
- 巴扎黑원래의
- 2017-07-20 16:03:522078검색
post: 처리할 데이터를 지정된 리소스에 제출합니다. 데이터 길이는 무제한이고 캐시할 수 없으며 브라우저 기록에 저장할 수 없으며 보안이 매우 뛰어납니다. POST는 GET보다 안정적이고 신뢰할 수 있습니다.
1. HTTP 사양에 따르면 GET은 정보 획득에 사용되며 안전하고 멱등성이 있어야 합니다.
(1) 소위 안전하다는 것은 정보를 수정하는 것이 아니라 정보를 얻는 데 사용되는 작업을 의미합니다. 즉, GET 요청에는 일반적으로 부작용이 없어야 합니다. 즉, 데이터베이스 쿼리처럼 리소스 정보만 가져오며, 데이터를 수정하거나 추가하지 않으며 리소스 상태에 영향을 주지 않습니다.
* 참고: 여기서 보안이란 수정되지 않은 정보만을 의미합니다.
(2)는 동일한 URL에 대한 여러 요청이 동일한 결과를 반환해야 함을 의미합니다. 여기서는 멱등성의 개념을 다시 설명하겠습니다.
멱등성(idempotent, 멱등성)은 추상 대수학에서 흔히 발견되는 수학 또는 컴퓨터 과학 개념입니다.
불능에는 다음과 같은 정의가 있습니다.
단항 연산의 경우 연산이 범위 내 모든 숫자에 대해 여러 번 연산을 수행하면 연산으로 얻은 결과는 연산을 한 번 수행하여 얻은 결과와 같습니다. 작업은 멱등적이라고 합니다. 예를 들어, 절대값 연산이 예로 들어 있습니다. 실수 집합에는 abs(a)=abs(abs(a))가 있습니다.
쌍안 연산의 경우 연산에 참여하는 두 값이 같을 때 연산 결과가 연산에 참여하는 두 값과 같을 경우 해당 연산을 멱등하다고 합니다 , 예를 들어 두 숫자의 최대값을 찾는 것과 같습니다. 의 함수는 실수 집합에서 멱등적입니다. 즉, max(x,x) = x입니다.
위의 설명을 읽고 나면 GET 멱등성의 의미를 이해할 수 있을 것입니다.
그러나 실제 적용에서는 위의 두 가지 규정이 그렇게 엄격하지는 않습니다. 다른 사람의 기사를 인용하는 예: 예를 들어 뉴스 사이트의 첫 페이지는 지속적으로 업데이트됩니다. 두 번째 요청은 다른 배치의 뉴스를 반환하지만 작업은 항상 현재 뉴스를 반환하므로 여전히 안전하고 멱등성 있는 것으로 간주됩니다. 기본적으로 사용자가 링크를 열 때 자신의 관점에서 리소스가 변경되지 않았음을 확신할 수 있는 것이 목표라면,
2. HTTP 사양에 따르면 POST는 서버의 리소스를 수정할 수 있는 요청을 나타냅니다. 위의 예를 계속 인용하자면, 뉴스 웹사이트를 예로 들어보겠습니다. 뉴스에 대한 독자의 댓글은 댓글이 제출된 후 사이트의 리소스가 다르거나 수정되기 때문에 POST를 통해 구현되어야 합니다.
위의 내용은 HTTP 사양에서 GET 및 POST의 몇 가지 원칙 문제에 대해 간략하게 설명합니다. 그러나 실제로는 많은 사람들이 HTTP 사양을 따르지 않습니다.
1. 많은 사람들이 편의성을 추구하여 리소스 업데이트 시 GET을 사용합니다. 왜냐하면 POST는 FORM(form)으로 이동해야 하기 때문입니다. ), 조금 더 번거로울 것입니다.
2. 리소스 추가, 삭제, 수정, 확인은 실제로 GET/POST를 통해 완료할 수 있으며, PUT, DELETE를 사용할 필요가 없습니다.
3. 또 하나는 초기 웹 MVC 프레임워크 디자이너들이 URL을 추상적인 리소스로 의식적으로 처리하고 설계하지 않았기 때문에 더 심각한 문제는 기존 웹 MVC 프레임워크는 기본적으로 GET과 POST 두 가지 HTTP 메서드만 지원하지만 PUT과 DELETE 메서드는 지원한다는 점입니다. 지원되지 않습니다.
* MVC에 대한 간략한 설명: MVC는 원래 데스크톱 프로그램에 존재했습니다. M은 데이터 모델을 나타내고 V는 사용자 인터페이스를 나타내며 C는 컨트롤러를 나타냅니다. MVC를 사용하는 목적은 M과 V의 구현 코드를 분리하여 동일한 프로그램이 다른 표현을 사용할 수 있도록 하는 것입니다.
위의 세 가지 사항은 일반적으로 HTTP 사양을 엄격하게 준수하지 않는 이전 스타일을 설명합니다. 아키텍처가 발전하면서 이제 HTTP 사양을 지원하는 새로운 스타일이 등장하게 되었습니다. 여기서는 더 이상 설명하지 않겠습니다. "RESTful 웹 서비스"를 참조하세요.
원칙 문제에 대해 이야기한 후 표면적으로 GET과 POST의 차이점을 살펴보겠습니다.
1. GET에서 요청한 데이터는 URL에 추가됩니다(즉, 데이터는 다음 위치에 배치됩니다). HTTP 프로토콜 헤더), URL을 분할하고 ?로 데이터를 전송하고 매개변수를 &로 연결합니다(예: login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0%E5%A5%BD). 데이터가 영문/숫자라면 그대로 보내고, 공백이라면 +로 변환하고, 한자/기타 문자라면 BASE64로 직접 암호화하면 %E4와 같은 결과가 나옵니다. %BD%A0%E5%A5% BD, 여기서 %XX의 XX는 16진수 기호의 ASCII 표현입니다.
POST는 제출된 데이터를 HTTP 패키지의 본문에 배치합니다.
2. "GET 방식으로 제출하는 데이터는 최대 1024바이트까지만 가능합니다. 이론적으로 POST에는 제한이 없으며 더 많은 양의 데이터를 전송할 수 있습니다. 최대값은 IIS4에서 80KB, IIS5에서 100KB입니다."? ? !
위 문장을 다른 글에서 옮겨왔습니다. 사실 이렇게 말하는 것은 틀리고 부정확합니다.
(1) 우선 "GET으로 제출하는 데이터는 최대 1024바이트까지만 가능하다". GET은 URL을 통해 데이터를 제출하기 때문에 GET으로 제출할 수 있는 데이터의 양은 URL의 길이와 직접적인 관련이 있다. . 실제로 URL에는 매개변수 상한이 없으며 HTTP 프로토콜 사양은 URL 길이를 제한하지 않습니다. 이 제한은 특정 브라우저 및 서버에 의해 부과됩니다. IE의 URL 길이 제한은 2083바이트(2K+35)입니다. Netscape, FireFox 등 다른 브라우저의 경우 이론적으로 길이 제한이 없으며 운영 체제 지원에 따라 제한이 달라집니다.
이 제한은 매개변수 값 데이터 길이뿐만 아니라 전체 URL 길이에도 적용됩니다. [참고 5 참조]
(2) 이론적으로 POST에는 크기 제한이 없으며, HTTP 프로토콜 사양에서는 "80K/100K 크기 제한이 있습니다"라고 말하는 것은 정확하지 않습니다. 데이터 볼륨." POST 데이터에는 제한이 없습니다. 제한은 서버 핸들러의 처리 능력입니다.
ASP 프로그램의 경우 요청 개체는 각 양식 필드를 처리할 때 데이터 길이 제한이 100K입니다. 그러나 Request.BinaryRead를 사용하면 그러한 제한이 없습니다.
이에 더해 Microsoft는 IIS 6.0에 대해 보안상의 이유로 제한을 강화했습니다. 또한 다음 사항에 주의해야 합니다.
1) IIS 6.0의 기본 ASP POST 데이터 볼륨은 최대 200KB이며 각 양식 필드의 제한은 100KB입니다.
2).IIS 6.0에서 업로드되는 파일의 기본 최대 크기는 4MB입니다.
3) IIS 6.0의 기본 최대 요청 헤더는 16KB입니다.
IIS 6.0 이전에는 이러한 제한이 없었습니다. [참고 5 참조]
그러니까 위의 80K와 100K는 그냥 기본값일 수도 있지만(참고: IIS4와 IIS5의 매개변수는 확인하지 않았습니다), 물론 직접 설정할 수도 있습니다. IIS 버전마다 이러한 매개변수의 기본값이 다르기 때문에 자세한 내용은 관련 IIS 구성 설명서를 참조하세요.
3. ASP에서 서버는 Request.QueryString을 사용하여 GET 요청 매개변수를 얻고 Request.Form을 사용하여 POST 요청 매개변수를 얻습니다. JSP에서는 request.getParameter("XXXX")를 사용하여 이를 얻습니다. jsp에도 request.getQueryString() 메소드가 있지만 사용하기가 더 번거롭습니다. 예를 들어 test.jsp?name=hyddd&password=를 전달하십시오. hyddd, 요청을 사용하세요. getQueryString()은 이름=hyddd&password=hyddd를 가져옵니다. PHP에서는 $_GET 및 $_POST를 사용하여 각각 GET 및 POST에서 데이터를 얻을 수 있는 반면, $_REQUEST는 GET 및 POST 요청 모두에서 데이터를 얻을 수 있습니다. JSP에서 요청을 사용하고 PHP에서 $_REQUEST를 사용하는 데에는 숨겨진 위험이 있다는 점은 주목할 가치가 있습니다. 다음에 기사 요약을 작성하겠습니다.
4.POST가 GET보다 더 안전합니다. 참고: 여기서 언급된 보안은 위의 GET에서 언급된 "보안"과 동일한 개념이 아닙니다. 위의 "보안"의 의미는 데이터 수정이 이루어지지 않는다는 것이며 여기서 보안의 의미는 보안의 진정한 의미입니다. 예를 들어 GET을 통해 데이터를 제출하면 사용자 이름과 비밀번호가 URL에 일반 텍스트로 표시됩니다. , (1) 로그인 페이지가 브라우저 캐시일 수 있고 (2) 다른 사람이 브라우저 기록을 본 다음 다른 사람이 귀하의 계정과 비밀번호를 얻을 수 있기 때문입니다. 또한 GET을 사용하여 데이터를 제출하면 교차 사이트 요청 위조 공격이 발생할 수도 있습니다.
요약하자면 Get은 서버에 데이터를 요청하는 것이고 Post는 데이터를 서버에 제출하라는 요청입니다. FORM(form)에서 Method의 기본값은 "GET"입니다. 본질적으로 GET과 POST는 The입니다. 전송 메커니즘이 다릅니다. 하나를 취하고 하나를 보내는 것이 아닙니다!
위 내용은 게시 요청과 요청 받기의 차이점을 구문 분석합니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!