1. Causes du problème
Dans la pièce jointe « Problèmes post-publication » des statistiques de bugs après la publication d’un projet, il y a :
En tant qu’accumulation d’expérience, ces problèmes, causes et solutions seront inclus dans la checklist, puis :
La première question : La limite supérieure du paramètre URL est-elle une référence exacte ? Quelle est la limite supérieure ?
Deuxième question : pourquoi y a-t-il une limite de données lors du POST ? La limite est-elle de 128 000 ?
2. Analyse du problème
1. Le premier :
1) Il n’y a pas de limite supérieure de paramètres dans l’URL. Le problème, c’est en fait qu’IE a une limite de longueur sur les URL.
2) La spécification du protocole HTTP ne limite pas non plus la longueur de l’URL. Cette limite est imposée par un navigateur et un serveur spécifiques. La limite d’URL d’IE est de 2083 octets (2K+35). Pour d’autres navigateurs comme Netscape, Firefox, etc., il n’existe pas de limite théorique de longueur, et cette limite dépend du support du système d’exploitation. [Réf. 1]
3) « Les paramètres de longueur variable sont transmis via URL » signifie en réalité que la méthode GET est utilisée lors de la soumission du formulaire, et non la méthode POST. Ce qui cause cette erreur potentielle est l’utilisation de la méthode GET pour soumettre les données du formulaire. Parce que la méthode GET transmet les données de l’URL au serveur pour traitement.
4) Notez que cette limite correspond à toute la longueur de l’URL, pas seulement à la valeur de votre paramètre et à la longueur des données.
5) Puisque c’est la limite d’IE sur la longueur de l’URL, la méthode GET et la méthode POST ont toutes deux cette limite.
(Veuillez consulter le document associé pour plus de détails sur les méthodes GET et POST du FORM [Réf. 2])
Recommandations :
1) Comprendre l’environnement dans lequel se trouve l’application, comme le navigateur et l’environnement serveur de l’application web, et comprendre ses limites spécifiques de paramètres.
2) Utiliser la méthode POST autant que possible pour soumettre des données complexes. Note : Lorsque FORM n’écrit pas l’attribut de la méthode, par défaut il faut utiliser la méthode GET.
Conclusion (écrire à la liste de contrôle) :
Lors de la soumission de données en utilisant la méthode GET, vous devez prendre en compte la limite de longueur d’URL de 2083 octets dans l’environnement IE.
2. La seconde :
1) Théoriquement, POST n’a pas de limite de taille. La spécification du protocole HTTP n’a pas non plus de limite de taille.
2) « Il existe une limite de taille de 128K pour les données POST » n’est pas assez précis, il n’y a pas de limite aux données POST, et la puissance de traitement du processeur du serveur joue un rôle limitant.
3) Pour les programmes ASP, il existe une limite de longueur de données de 100K lorsque l’objet Request traite chaque champ de formulaire. Mais avec Request.BinaryRead, il n’y a pas de telle limitation. Pour les solutions nécessitant un traitement de plus de 100 000 données du domaine du form, veuillez consulter [Réf. 3] ci-dessous.
4) Par extension, pour IIS 6.0, Microsoft a renforcé les restrictions pour des raisons de sécurité [Réf. 4]. Nous devons également prêter attention à :
IIS 6.0 est par défaut un maximum de 200 Ko de données ASP POST, et la limite est de 100 Ko par champ de formulaire.
La taille par défaut des fichiers d’envoi IIS 6.0 est de 4 Mo.
IIS 6.0 met par défaut un en-tête de requête maximum de 16 Ko.
Ces limitations n’étaient pas disponibles avant IIS 6.0.
Recommandations :
1) Connaître les paramètres par défaut de l’environnement de course vous aidera à concevoir et à résoudre rapidement les problèmes qui surviennent.
2) La version serveur doit être envisagée. Chaque version d’IIS dispose de paramètres par défaut différents pour ces paramètres, donc si nécessaire, trouvez des informations et compilez une table de comparaison. Ainsi, il y a une référence pour le développement et les tests.
3) Ces limitations d’IIS 6.0 ne sont en réalité que ses paramètres par défaut, et vous pouvez les modifier dans l’environnement applicatif réel.
Dans WINNT/system32/inetsrv/MetaBase.xml, la définition par défaut est la suivante :
AspBufferingLimit="4194304 » correspond à la taille maximale du fichier téléchargé
AspMaxRequestEntityAllowed = = 204800 » correspond à la quantité maximale de données dans POST
...
Conclusion (écrire à la liste de contrôle) :
Lorsque vous utilisez ASP, vous devez prendre en compte que le formulaire POST a une limite de 100 Ko par champ pour le traitement général de la lecture. Réfléchissez à l’utilisation de Request.Binary.
|
Publié sur 08/03/2018 10:18:07
|
|
|
|
