Comment résoudre la valeur incohérente de la session en constante évolution dans l'accès Ajax et la différence entre GET et POST dans le protocole HTTP

Cet article présente principalement la solution à la valeur incohérente du changement de session dans l'accès Ajax et les informations pertinentes sur la différence entre GET et POST dans le protocole HTTP. Les amis qui en ont besoin peuvent s'y référer

. J'en fais un aujourd'hui, j'ai rencontré un problème lors de l'utilisation de la barre de progression. J'ai stocké un compteur dans la session lorsqu'une donnée était explorée, la valeur était de +1, puis la réception obtenait la valeur de la session tous les 3. secondes, mais le problème est apparu. Sous FF, les valeurs obtenues sont normales, mais sous IE, ce sont les valeurs précédentes. Ce n'est qu'à la réouverture de la page que la dernière valeur de session peut être obtenue :

<.>Ce qui suit est le mien Le code de 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>

PS : Concernant HTTP GET et POST

1. Selon la spécification HTTP, GET est utilisé pour l'acquisition d'informations et doit être sûr et idempotent. 　

L'impuissance a les définitions suivantes : 　

2. Selon la spécification HTTP, POST représente une requête pouvant modifier les ressources sur le serveur.

Mais dans la pratique, de nombreuses personnes ne suivent pas les spécifications HTTP. Il existe de nombreuses raisons à ce problème, telles que : <.>1. Beaucoup de gens sont avides de commodité et utilisent GET lors de la mise à jour des ressources, car l'utilisation de POST doit accéder au FORM (formulaire), ce qui sera un peu gênant. ​

2. L'ajout, la suppression, la modification et la vérification des ressources peuvent en fait être effectués via GET/POST, et il n'est pas nécessaire d'utiliser PUT et DELETE.

3. Un autre problème est que les premiers concepteurs du framework Web MVC n'ont pas consciemment traité et conçu les URL comme des ressources abstraites. Par conséquent, un problème plus grave est que le framework Web MVC traditionnel ne prend en charge que les deux méthodes HTTP. GET et POST, mais pas les méthodes PUT et DELETE. ​

MVC existait à l'origine dans le programme Desktop M fait référence au modèle de données, V fait référence à l'interface utilisateur et C fait référence au modèle de données. contrôleur. Le but de l'utilisation de MVC est de séparer les codes d'implémentation de M et V, afin que le même programme puisse utiliser des représentations différentes.

Les trois points ci-dessus décrivent généralement l'ancien style (qui n'adhère pas strictement à la spécification HTTP). Avec le développement de l'architecture, REST (RepresentationalState Transfer) apparaît désormais, un nouveau style qui prend en charge la spécification HTTP. Il n'y en a pas beaucoup ici. Cela dit, vous pouvez vous référer aux « RESTful Web Services ». ​

(1).Tout d'abord, "les données soumises par GET ne peuvent contenir que 1 024 octets". Étant donné que GET soumet les données via une URL, la quantité de données pouvant être soumises par GET est directement liée à la longueur de. l'URL. En fait, il n'y a pas de limite supérieure de paramètre pour les URL, et la spécification du protocole HTTP ne limite pas la longueur des URL. Cette limite est imposée par des navigateurs et des serveurs spécifiques. La limite d'IE en matière de longueur d'URL est de 2 083 octets (2 Ko+35). Pour les autres navigateurs, tels que Netscape, FireFox, etc., il n'y a théoriquement aucune limite de longueur, et la limite dépend du support du système d'exploitation. Notez que cette limite correspond à la longueur totale de l'URL, et pas seulement à la longueur des données de la valeur de votre paramètre.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!