Ajax 액세스에서 끊임없이 변화하는 세션의 일관되지 않은 값과 HTTP 프로토콜의 GET과 POST의 차이점을 해결하는 방법-JS 튜토리얼-php.cn

이 글에서는 Ajax 접속 시 세션 변경의 불일치 값에 대한 해결 방법과 HTTP 프로토콜의 GET과 POST의 차이점에 대한 관련 정보를 주로 소개합니다. 필요하신 분들은 참고하시면 됩니다.

오늘 우연히 접하게 되었습니다. 진행률 표시줄을 만드는 중이었는데 세션에 카운터를 저장했는데 데이터가 크롤링되면 값이 +1이 되고 프런트 데스크에서 3초마다 세션 값을 가져오는데 문제가 발생합니다. FF에서는 얻은 값이 모두 정상이지만 IE에서는 이전 값이 그대로 유지됩니다. 페이지를 다시 열어야 최신 세션 값을 얻을 수 있습니다.

다음은 내 proBar.jsp의 코드입니다.

<%@ page language="java" import="java.util.*" pageEncoding="UTF-"%>
<%
String path = request.getContextPath();
String basePath = request.getScheme()+"://"+request.getServerName()+":"+request.getServerPort()+path+"/";
%>
<script type="text/javascript" src="<%=path %>/js/jquery.js"></script>
<script type="text/javascript" src="<%=path%>/js/jquery.progressbar.min.js"></script>
<script type="text/javascript">
function createXMLHttpRequest() {
  var xmlHttp;
  if (window.ActiveXObject) {
   xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");
  } else {
   xmlHttp = new XMLHttpRequest();
  }
  return xmlHttp;
 }
 function btn_click() {
  var xmlHttp; 
  xmlHttp = createXMLHttpRequest();
  xmlHttp.onreadystatechange = processor;
  //xmlHttp.open("GET", "/jbbs/servlet/ControlCrawl?method=getinforsize", true);
  xmlHttp.open("POST", "/jbbs/servlet/ControlCrawl?method=getinforsize", true);
  xmlHttp.send(null);
  function processor() {
   .......
  }
 }
 var action=setInterval("btn_click();", );
 </script>
<span>爬取进度:</span><br/>
<p id="container"></p>

로그인 후 복사

나중에 GET을 POST로 변경하니 정상이 되었습니다.

PS: HTTP GET 및 POST에 관하여

Http는 서버와 상호 작용하는 다양한 방법을 정의합니다. 즉, GET, POST, PUT 및 DELETE라는 4가지 가장 기본적인 방법이 있습니다. URL의 전체 이름은 리소스 설명자(Resource Descriptor)라고 생각하면 됩니다. URL 주소는 네트워크의 리소스를 설명하는 데 사용되며 HTTP의 GET, POST, PUT 및 DELETE는 검색, 수정 및 추가에 해당합니다. 이 리소스의 작업 4개를 삭제하세요. 이 시점에서 모든 사람은 일반적으로 GET은 리소스 정보를 얻거나 쿼리하는 데 사용되는 반면 POST는 일반적으로 리소스 정보를 업데이트하는 데 사용됩니다.

1. HTTP 사양에 따르면 GET은 정보 획득에 사용되며 안전하고 멱등성이 있어야 합니다. 　

(1) 소위 안전이란 정보를 수정하는 것이 아니라 정보를 얻는 데 사용되는 작업을 의미합니다. 즉, GET 요청에는 일반적으로 부작용이 없어야 합니다. 즉, 데이터베이스 쿼리처럼 리소스 정보만 가져오며, 데이터를 수정하거나 추가하지 않으며 리소스 상태에 영향을 주지 않습니다.

* 참고: 여기서 보안이란 수정되지 않은 정보만을 의미합니다.

(2)는 동일한 URL에 대한 여러 요청이 동일한 결과를 반환해야 함을 의미합니다.

Impotence(멱등성, 멱등성)은 추상 대수학에서 흔히 발견되는 수학 또는 컴퓨터 과학 개념입니다.

무력에는 다음과 같은 정의가 있습니다. 　

단항 연산의 경우 범위 내의 모든 숫자에 대해 연산을 여러 번 수행하면 연산을 여러 번 수행하여 얻은 결과는 해당 연산을 수행하여 얻은 결과와 같습니다. 한 번만 수행하면 해당 작업이 멱등적이라고 말합니다. 예를 들어, 절대값 연산이 예로 들어 있습니다. 실수 집합에는 abs(a)=abs(abs(a))가 있습니다.

쌍안경 연산의 경우 연산에 참여하는 두 값이 같을 때 연산 결과가 연산에 참여하는 두 값과 같을 경우 연산을 이라고 합니다. 두 숫자의 최대값을 찾는 것과 같은 멱등성. 값의 함수는 실수 집합, 즉 max(x,x) = x에서 멱등성을 갖습니다.

하지만 실제 적용에서는 위의 두 가지 규정이 그리 엄격하지는 않습니다. 다른 사람의 기사를 인용하는 예: 예를 들어 뉴스 사이트의 첫 페이지는 지속적으로 업데이트됩니다. 두 번째 요청은 다른 배치의 뉴스를 반환하지만 작업은 항상 현재 뉴스를 반환하므로 여전히 안전하고 멱등성 있는 것으로 간주됩니다. 기본적으로 사용자가 링크를 열 때 자신의 관점에서 리소스가 변경되지 않았음을 확신할 수 있는 것이 목표라면,

2. HTTP 사양에 따르면 POST는 서버의 리소스를 수정할 수 있는 요청을 나타냅니다.

계속해서 위의 예를 인용해 보겠습니다. 뉴스 웹사이트를 예로 들어 보겠습니다. 뉴스에 대한 독자의 댓글은 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 사양을 지원하는 새로운 스타일인 REST(RepresentationalState Transfer)가 등장하게 됩니다. 여기서는 더 이상 설명하지 않겠습니다. "RESTful 웹 서비스"를 참조하세요.

표면적으로 GET과 POST의 차이점을 살펴보겠습니다.

(1) 우선, "GET으로 제출하는 데이터는 최대 1024바이트까지만 가능합니다." GET은 URL을 통해 데이터를 제출하기 때문에 GET으로 제출할 수 있는 데이터의 양은 URL의 길이와 직접적인 관련이 있습니다. . 실제로 URL에는 매개변수 상한이 없으며 HTTP 프로토콜 사양은 URL 길이를 제한하지 않습니다. 이 제한은 특정 브라우저 및 서버에 의해 부과됩니다. IE의 URL 길이 제한은 2083바이트(2K+35)입니다. Netscape, FireFox 등 다른 브라우저의 경우 이론적으로 길이 제한이 없으며 운영 체제 지원에 따라 제한이 달라집니다. 이 제한은 매개변수 값 데이터 길이뿐만 아니라 전체 URL 길이에도 적용됩니다.

(2) 이론적으로 POST에는 크기 제한이 없으며, HTTP 프로토콜 사양에서는 "POST 데이터 볼륨에 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 이전에는 이러한 제한이 없었습니다.

그래서 위의 80K와 100K는 단지 기본값일 수도 있지만(참고: IIS4 및 IIS5의 매개변수는 아직 확인하지 않았습니다), 확실히 직접 설정할 수 있습니다. IIS 버전마다 이러한 매개변수의 기본값이 다르기 때문에 자세한 내용은 관련 IIS 구성 설명서를 참조하세요.

3. ASP에서 서버는 Request.QueryString을 사용하여 GET 요청 매개변수를 얻고 Request.Form을 사용하여 POST 요청 매개변수를 얻습니다.

JSP에서는 request.getParameter("XXXX")를 사용하여 jsp에도 request.getQueryString() 메서드가 있지만 사용하기가 더 번거롭습니다. name=hyddd&password=hyddd , request.getQueryString()을 사용하여 다음을 얻으세요: name=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입니다. 전송 메커니즘이 다릅니다. 하나를 취하고 하나를 보내는 것이 아닙니다!

위 내용은 모두를 위해 제가 정리한 내용입니다. 앞으로 모든 사람에게 도움이 되기를 바랍니다.