plinfos

Un malentendu sur la longueur maximale des paramètres de requête HTTP GET/POST – Blue Sky Eternity – 博客园


Il n’y a pas de limite à la taille et à la longueur des données soumises par la méthode Http Get, et la spécification du protocole HTTP ne limite pas la longueur de l’URL. Cette limitation est une limitation imposée par des navigateurs et des serveurs spécifiques.

Par exemple : IE limite la longueur de l’URL à 2 083 octets (2 K+35).

Ce qui suit est une description des capacités de traitement maximales de divers navigateurs et serveurs.

Microsoft Internet Explorer (navigateur)

Le navigateur IE a une limite maximale de 2083 caractères pour l’URL, s’il dépasse ce nombre, le bouton Soumettre ne répond pas.
Firefox (navigateur)

Pour Firefox, la limite de longueur d’URL est de 65 536 caractères.

Safari (Navigateur)

La longueur maximale de l’URL est limitée à 80 000 caractères.

Opéra (Navigateur)

La longueur maximale de l’URL est limitée à 190 000 caractères.

Google Chrome)

La longueur maximale de l’URL est limitée à 8182 caractères.

Apache (serveur)

La longueur d’URL maximale pouvant être acceptée est de 8 192 caractères.

Microsoft Internet Information Server (IIS)

La longueur maximale d’URL pouvant être acceptée est de 16 384 caractères.

Selon les données ci-dessus, afin de permettre à tous les utilisateurs de naviguer normalement, l’URL ne doit pas dépasser la limite de longueur maximale d’IE (2083 caractères). Bien sûr, si l’URL n’est pas directement fournie à l’utilisateur, mais au programme call, this La durée n’est affectée que par le serveur Web.

Remarque : Pour la transmission des caractères chinois, il sera transmis sous forme encodée après urlencode. Si l’encodage du navigateur est UTF8, la longueur finale des caractères encodés d’un caractère chinois est de 9 caractères.

Ainsi, si la méthode GET est utilisée, la longueur maximale est égale à la longueur maximale de l’URL moins le nombre de caractères dans le chemin réel.

En théorie, POST n’a pas de limite de taille. La spécification du protocole HTTP ne limite pas la taille, mais la capacité de traitement du programme de traitement du serveur joue un rôle limitatif.

Par exemple : annulez la limite de taille POST sous Tomcat (Tomcat est par défaut de 2 M) ;

Ouvrez le répertoire conf sous le répertoire tomcat, ouvrez le fichier server.xml et modifiez

debug= »0″

acceptCount= »100″

connectionTimeout= »20000″

disableUploadTimeout= »true »

port= »8080″

redirectPort= »8443″

enableLookups= »false »

minSpareThreads= »25″

maxSpareThreads= »75″

maxThreads= »150″

maxPostSize= »0″

URIEncoding= »GBK »

>

Augmentez la partie de police rouge maxPostSize= »0″ (réglée sur 0 pour annuler la limite de taille de POST)

Je viens de voir des étudiants du groupe dire que la longueur des paramètres de requête Get sous le protocole HTTP a une limite de taille et que le maximum ne peut pas dépasser

XX, et la publication est illimitée. Voyant cela, je pense qu’ils ont dû lire des blogs ou des livres qui propagent des rumeurs.

conduire à un malentendu dans la compréhension :

1. Tout d’abord, même s’il y a une limite de longueur, la limite est la longueur entière de l’URI, pas seulement la longueur des données de la valeur de votre paramètre.

2. Le protocole HTTP n’a jamais stipulé la limite de longueur de requête de GET/POST.

Le protocole HTTP n’impose aucune limite a priori sur la longueur d’un URI. Les serveurs DOIVENT être capables de gérer l’URI de toute ressource qu’ils desservent, et DEVRAIENT être capables de gérer des URI de longueur illimitée s’ils fournissent des formes basées sur GET qui pourraient générer de tels URI. Un serveur DEVRAIT retourner l’état 414 (Request-URI Too Long) si un URI est plus long que ce que le serveur peut gérer (voir au paragraphe 10.4.15).

Remarque : Les serveurs doivent être prudents lorsqu’ils dépendent de longueurs d’URI supérieures à 255 octets, car certaines implémentations clientes ou proxy plus anciennes peuvent ne pas prendre correctement en charge ces longueurs.

3. La soi-disant limite de longueur de requête est déterminée et définie par le navigateur et le serveur Web, ainsi que par les paramètres de divers navigateurs et serveurs Web.

Tous sont différents, qui dépendent des réglementations de chaque fabricant de navigateur ou peuvent être définis en fonction de la capacité de traitement du serveur Web.

La limite est dans MSIE et Safari d’environ 2 Ko, dans Opera d’environ 4 Ko et dans Firefox d’environ 8 Ko, (255 octets si l’on compte les très anciens navigateurs). Nous pouvons donc supposer que 8 Ko est la longueur maximale possible et que 2 Ko est une longueur plus abordable sur laquelle compter côté serveur et que 255 octets est la longueur la plus sûre pour supposer que l’URL entière entrera.

Si la limite est dépassée dans le navigateur ou le serveur, la plupart tronqueront simplement les caractères en dehors de la limite sans aucun avertissement. Certains serveurs peuvent cependant envoyer une erreur HTTP 414. Si vous avez besoin d’envoyer des données volumineuses, il vaut mieux utiliser POST au lieu de GET. SA limite est beaucoup plus élevée, mais plus dépendante du serveur utilisé que du client. Habituellement, jusqu’à environ 2 Go sont autorisés par le serveur Web moyen. Ceci est également configurable quelque part dans les paramètres du serveur. Le serveur moyen affichera une erreur/exception spécifique au serveur lorsque la limite POST est dépassée, généralement sous la forme d’une erreur HTTP 500.

HTTP 1.1 définit le code d’état 414 Request-URI Too Long pour les cas où une limite définie par le serveur est atteinte. Vous pouvez voir plus de détails sur RFC 2616. Pour le cas des limites définies par le client, il n’y a aucun sens à ce que le serveur renvoie quelque chose, car le serveur ne recevra pas du tout la demande.

Le serveur refuse de traiter la demande car l’URI de la demande est plus long que ce que le serveur est prêt à interpréter. Cette condition rare n’est susceptible de se produire que lorsqu’un client a incorrectement converti une requête POST en une requête GET avec de longues informations de requête, lorsque le client est descendu dans un « trou noir » URI de redirection (par exemple, un préfixe URI redirigé qui pointe vers un suffixe de lui-même), ou lorsque le serveur est attaqué par un client tentant d’exploiter les failles de sécurité présentes dans certains serveurs en utilisant des tampons de longueur fixe pour lire ou manipuler le Request-URI.

Attaché GET VS POST :

1. La plupart des navigateurs envoient des données en deux étapes pour POST, d’abord envoyer l’en-tête de la requête, puis envoyer le corps de la requête. Même si les paramètres sont peu nombreux et courts, ils seront envoyés en deux étapes (par rapport à GET), c’est-à-dire La première étape consiste à envoyer les données d’en-tête et la deuxième étape consiste à envoyer la partie du corps. HTTP est un protocole de couche application et, dans certains cas, au niveau de la couche transport, TCP aura deux connexions.Le protocole HTTP lui-même n’enregistre pas les informations d’état, et une demande et une réponse. Pour TCP, plus les temps de communication sont longs, plus la fiabilité est faible. Il est le plus fiable pour transmettre les messages requis en une seule connexion. Essayez d’utiliser les requêtes GET pour réduire la consommation de temps du réseau. Si le temps de communication augmente, le client et le serveur restent connectés pendant cette période, la charge sur le serveur peut augmenter et la fiabilité diminuer.

Astuces : Pour ce point, vous pouvez vous référer à : Yahoo Website Performance Optimization Guide – Server Articles

http://segmentfault.com/a/1190000000353790

http://developer.yahoo.com/performance/rules.html

http://blogread.cn/it/article/6100?f=wb Dans la règle YSLOW, pourquoi Yahoo recommande-t-il GET au lieu de POST ?

L’article ci-dessus présente l’ensemble du processus de capture de paquets wireshark pour vérifier que post envoie des paquets deux fois et qu’il envoie des paquets une fois.

2. Les requêtes GET peuvent être mises en cache et les requêtes GET peuvent être enregistrées dans l’historique de navigation du navigateur (les mots de passe et autres données importantes sont soumis par GET, et d’autres peuvent voir directement ces données privées lors de la visualisation des enregistrements d’historique).POST n’est pas mis en cache.

3. Le paramètre GET est suivi de l’URL. La longueur maximale disponible de l’URL dans IE traditionnel est de 2 048 caractères. D’autres navigateurs ont différentes implémentations de la limite de longueur d’URL. Il n’y a pas de limite de longueur pour les requêtes POST (actuellement c’est théoriquement le cas).

4. La taille des données soumises par GET a des restrictions différentes pour différents navigateurs, généralement entre 2 000 et 8 000. Les données soumises par POST sont relativement volumineuses, et la taille est limitée par la valeur de réglage du serveur, et certaines données ne peuvent que être « porté » par la méthode POST , telle que file.

5. Il n’est pas très raisonnable d’utiliser tous les POSTs. Il est préférable de classer les requêtes selon les fonctions et les scénarios. Pour les requêtes de données fréquentes, les données ne sont pas sensibles et le volume de données est dans la limite minimale de 2k pour les navigateurs ordinaires. Dans ce cas, utilisez GET. Ailleurs, utilisez POST.

6. L’essence de GET est « obtenir », tandis que l’essence de POST est « donner ». De plus, GET est « idempotent », à ce stade, GET est considéré comme « sûr ». Mais en fait, le côté serveur peut également être utilisé pour la mise à jour des ressources, mais cette utilisation viole l’accord et est facile à provoquer CSRF (cross-site request forgery).

RÉF:

longueur maximale de la requête HTTP GET ?

http://stackoverflow.com/questions/2659952/maximum-length-of-http-get-request

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.15 Demande-URI trop long

http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2.1 Syntaxe générale

http://www.cnblogs.com/xiaotaomaomao/articles/986070.html

http://www.cnblogs.com/TankXiao/archive/2012/02/13/2342672.html Explication détaillée du protocole HTTP

La méthode post est plus sûre que la méthode get, et elle contient plus de données. Je prévois d’utiliser la méthode post pour obtenir toutes les données, est-ce que ça va ?

http://segmentfault.com/q/1010000000213082

http://www.cnblogs.com/hyddd/archive/2009/04/09/1432744.html Parler des méthodes d’attaque CSRF

C’est-à-dire que je ne connais pas la limite de taille de la requête get, car le protocole http ne limite pas la taille et la limite de taille définie par les différents fabricants de navigateurs est différente.Vidéo fastdfs 06 13:56

Original : http://blog.chinaunix.net/uid-26602509-id-4495786.html

Source link

Laisser un commentaire