1. Oorzaken van het probleem
In de bijlage "Post-Release Problems" van de bugstatistieken na de release van een project staan er:
Als ervaringsverzameling worden deze problemen, oorzaken en oplossingen opgenomen in de checklist, en dan:
De eerste vraag: Is de bovengrens van de URL-parameter een nauwkeurige referentie? Wat is de bovengrens?
Tweede vraag: Waarom is er een limiet op data bij POST? Is de limiet 128K?
2. Probleemanalyse
1. De eerste:
1) Er is geen bovengrens aan parameters in de URL. Het probleem is eigenlijk dat IE een lengtelimiet heeft voor URL's.
2) De HTTP-protocolspecificatie beperkt ook de lengte van de URL niet. Deze limiet is een beperking die wordt opgelegd door een specifieke browser en server. IE's limiet op URL-lengte is 2083 bytes (2K+35). Voor andere browsers zoals Netscape, Firefox, enzovoort, is er geen theoretische lengtelimiet, en hangt de limiet af van de ondersteuning van het besturingssysteem. [Ref. 1]
3) "Variabele parameters worden via URL doorgegeven" betekent eigenlijk dat de GET-methode wordt gebruikt bij het indienen van het formulier, niet de POST-methode. Wat deze mogelijke fout veroorzaakt, is het gebruik van de GET-methode om formuliergegevens in te dienen. Omdat de GET-methode de gegevens in de URL doorgeeft aan de server voor verwerking.
4) Let op: deze limiet is de volledige URL-lengte, niet alleen de lengte van je parameterwaarde.
5) Omdat het IE's limiet is op URL-lengte, hebben zowel de GET-methode als de POST-methode deze beperking.
(Raadpleeg het gerelateerde document voor details over de GET- en POST-methoden van FORM [Ref. 2])
Aanbevelingen:
1) De omgeving begrijpen waarin de applicatie zich bevindt, zoals de browser- en serveromgeving van de webapplicatie, en de specifieke parameterbeperkingen ervan begrijpen.
2) Gebruik de POST-methode zoveel mogelijk om complexe gegevens in te dienen. Opmerking: Wanneer FORM het methode-attribuut niet schrijft, is de standaard het gebruik van de GET-methode.
Conclusie (schrijf naar de checklist):
Bij het indienen van data met de GET-methode moet je rekening houden met de URL-lengtelimiet van 2083 bytes in de IE-omgeving.
2. De tweede:
1) Theoretisch heeft POST geen groottelimiet. De HTTP-protocolspecificatie kent ook geen groottelimiet.
2) "Er is een groottelimiet van 128K voor POST-data" is niet nauwkeurig genoeg, er is geen limiet aan POST-data, en de verwerkingskracht van de processor van de server speelt een beperkende rol.
3) Voor ASP-programma's is er een limiet van 100K datalengte wanneer het Request-object elk formulierveld verwerkt. Maar met Request.BinaryRead is er geen dergelijke beperking. Voor oplossingen die meer dan 100.000 formulierdomeingegevens vereisen, zie hieronder [Ref. 3].
4) Bij uitbreiding heeft Microsoft voor IIS 6.0 de beperkingen om veiligheidsredenen verhoogd [Ref. 4]. We moeten ook letten op:
IIS 6.0 is standaard maximaal 200 KB ASP POST-data, en de limiet is 100 KB per formulierveld.
De standaardgrootte van IIS 6.0 uploadbestanden is 4MB.
IIS 6.0 heeft standaard een maximale requestheader van 16KB.
Deze beperkingen waren niet beschikbaar vóór IIS 6.0.
Aanbevelingen:
1) Het kennen van de standaardinstellingen van de lopende omgeving helpt je bij het ontwerpen en snel oplossen van problemen die zich voordoen.
2) Serverversie moet worden overwogen. Elke versie van IIS heeft verschillende standaardinstellingen voor deze parameters, dus indien nodig, zoek informatie en stel een vergelijkingstabel samen. Op deze manier is er een referentie voor ontwikkeling en testen.
3) Deze beperkingen van IIS 6.0 zijn eigenlijk gewoon de standaardinstellingen, en je kunt ze aanpassen in de daadwerkelijke applicatieomgeving.
In WINNT/system32/inetsrv/MetaBase.xml is de standaarddefinitie:
AspBufferingLimit="4194304" komt overeen met de maximale grootte van het geüploade bestand
AspMaxRequestEntityAllowed="204800" komt overeen met de maximale hoeveelheid data in POST
...
Conclusie (schrijf naar de checklist):
Bij het gebruik van ASP moet je rekening houden met het feit dat het POST-formulier een limiet van 100KB per veld heeft voor algemene leesverwerking. Overweeg of je Request.Binary wilt gebruiken.
|
Geplaatst op 08-03-2018 10:18:07
|
|
|
|
