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>

Plus tard, il était normal de changer GET en POST.

PS : Concernant HTTP GET et POST

Http définit différentes méthodes d'interaction avec le serveur. Il existe 4 méthodes les plus basiques. GET, POST, PUT et DELETE. Le nom complet de l'URL est un descripteur de ressource. On peut y penser de cette façon : une adresse URL est utilisée pour décrire une ressource sur le réseau, et GET, POST, PUT et DELETE en HTTP correspondent à la recherche, la modification et l'ajout. de cette ressource. Supprimer 4 opérations. À ce stade, tout le monde devrait avoir une compréhension générale. GET est généralement utilisé pour obtenir/interroger des informations sur les ressources, tandis que POST est généralement utilisé pour mettre à jour les informations sur les ressources. ​

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

(1). Le soi-disant coffre-fort signifie que l'opération est utilisée pour obtenir des informations plutôt que pour modifier des informations. En d’autres termes, les requêtes GET ne devraient généralement pas avoir d’effets secondaires. C'est-à-dire qu'il obtient uniquement des informations sur la ressource, tout comme une requête de base de données, il ne modifiera ni n'ajoutera de données et n'affectera pas l'état de la ressource. ​

* Remarque : Le sens de sécurité ici se réfère uniquement aux informations non modifiées. ​

(2). Idempotent signifie que plusieurs requêtes vers la même URL doivent renvoyer le même résultat. ​

L'idempotence (idempotent, idempotence) est un concept mathématique ou informatique que l'on retrouve couramment en algèbre abstraite.

L'impuissance a les définitions suivantes : 　

Pour les opérations unaires, si une opération est effectuée plusieurs fois sur tous les nombres de la plage, le résultat est Si le résultat est le même chose que le résultat de l’exécution de l’opération une fois, alors nous disons que l’opération est idempotente. Par exemple, l'arithmétique des valeurs absolues est un exemple. Dans l'ensemble des nombres réels, il y a abs(a)=abs(abs(a)).

Pour les opérations binoculaires, il faut que lorsque les deux valeurs participant à l'opération soient égales, si le résultat de l'opération est égal aux deux valeurs participant à l'opération, l'opération est dit idempotent. Par exemple, pour trouver deux La fonction avec la valeur maximale d'un nombre est idempotente dans l'ensemble des nombres réels, c'est-à-dire max(x,x) = x.

Mais dans la pratique, les deux réglementations ci-dessus ne sont pas si strictes. Exemples de citation d'articles d'autres personnes : Par exemple, la première page d'un site d'actualités est constamment mise à jour. Bien que la deuxième requête renvoie un lot d'informations différent, l'opération est toujours considérée comme sûre et idempotente car elle renvoie toujours les informations actuelles. Fondamentalement, si l'objectif est que lorsque l'utilisateur ouvre un lien, il puisse être sûr que la ressource n'a pas changé de son point de vue. ​

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

Pour continuer à citer l'exemple ci-dessus : en prenant l'actualité comme exemple, les lecteurs devraient faire leurs propres commentaires sur l'actualité via POST, car les ressources du site ont changé après la soumission des commentaires. , ou Il indique que la ressource a été modifiée.

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. ​

* À propos de MVC :

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 ». ​

Regardons la différence entre GET et POST depuis la surface : ​

(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.

(2). Théoriquement, il n'y a pas de limite de taille pour le POST, et la spécification du protocole HTTP n'impose pas de limite de taille. Il est inexact de dire que « la quantité de données POST a une limite de taille de 80 Ko ». /100K". Données POST Il n'y a pas de limite. La limite est la puissance de traitement du gestionnaire du serveur. ​

Pour les programmes ASP, il existe une limite de longueur de données de 100 Ko lorsque l'objet Request traite chaque champ de formulaire. Mais si vous utilisez Request.BinaryRead, une telle restriction n'existe pas.

À partir de cela, pour IIS 6.0, Microsoft a augmenté les restrictions pour des raisons de sécurité.

Nous devons également prêter attention à :

1). Le volume de données ASP POST par défaut d'IIS 6.0 est de 200 Ko et la limite de chaque champ de formulaire est de 100 Ko. . 　　

2). La taille maximale par défaut des fichiers téléchargés dans IIS 6.0 est de 4 Mo. 　　

3). L'en-tête de requête maximum par défaut d'IIS 6.0 est de 16 Ko. ​

De telles restrictions n’existaient pas avant IIS 6.0.

Donc, les 80K et 100K ci-dessus ne sont peut-être que les valeurs par défaut (remarque : je n'ai pas confirmé les paramètres d'IIS4 et IIS5), mais elles peuvent certainement être définies par vous-même. Étant donné que chaque version d'IIS a des valeurs par défaut différentes pour ces paramètres, veuillez vous référer à la documentation de configuration IIS correspondante pour plus de détails. ​

3. Dans ASP, le serveur utilise Request.QueryString pour obtenir les paramètres de requête GET et Request.Form pour obtenir les paramètres de requête POST.

Dans JSP, utilisez request.getParameter("XXXX") pour l'obtenir Bien qu'il existe également une méthode request.getQueryString() dans jsp, elle est plus difficile à utiliser. exemple : passez un test .jsp?name=hyddd&password=hyddd, utilisez request.getQueryString() pour obtenir : name=hyddd&password=hyddd. En PHP, vous pouvez utiliser $_GET et $_POST pour obtenir des données respectivement dans GET et POST, tandis que $_REQUEST peut obtenir des données dans les requêtes GET et POST. Il convient de noter qu'il existe des dangers cachés à utiliser request en JSP et $_REQUEST en PHP. J'écrirai un résumé de l'article la prochaine fois. ​

4. POST est plus sécurisé que GET.

Remarque : La sécurité mentionnée ici n'est pas le même concept que la "sécurité" mentionnée dans GET ci-dessus. La signification du terme « sécurité » ci-dessus est simplement qu'aucune modification des données n'est effectuée, et la signification du terme sécurité ici est la véritable signification de la sécurité. Par exemple : lors de la soumission de données via GET, le nom d'utilisateur et le mot de passe apparaîtront en texte clair sur l'URL. , car (1) la page de connexion peut être le cache du navigateur, (2) d'autres personnes consultent l'historique du navigateur, d'autres peuvent alors obtenir votre compte et votre mot de passe. De plus, l'utilisation de GET pour soumettre des données peut également provoquer des attaques de falsification de requêtes intersites.

Pour résumer, Get est une demande de données au serveur, tandis que Post est une demande de soumission de données au serveur. Dans FORM (formulaire), la méthode est par défaut "GET". POST n'a que des mécanismes d'envoi différents, aucun n'est pris et l'autre est envoyé !

Ce qui précède est ce que j'ai compilé pour vous. J'espère que cela vous sera utile à l'avenir.

Articles connexes :

Implémentation de la fonction de téléchargement de fichiers basée sur Ajax et HTML5 dans MVC

Comment résoudre la navigation ajax dans Échec de Google Chrome sur le serveur

Basé sur ajax pour réaliser un clic de chargement pour charger davantage sans actualiser cette page

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!