1. Årsager til problemet
I vedhæftningen "Post-Release Problems" med fejlstatistikkerne efter udgivelsen af et projekt findes:
Som en erfaringsakkumulering vil disse problemer, årsager og løsninger blive inkluderet i tjeklisten, og derefter:
Det første spørgsmål: Er den øvre grænse for URL-parameteren nøjagtig reference? Hvad er den øvre grænse?
Andet spørgsmål: Hvorfor er der en grænse for data, når man bruger POST? Er grænsen 128K?
2. Problemanalyse
1. Den første:
1) Der er ingen øvre grænse for parametre i URL'en. Problemet er faktisk, at IE har en længdebegrænsning på URL'er.
2) HTTP-protokolspecifikationen begrænser heller ikke URL'ens længde. Denne begrænsning er en begrænsning pålagt af en specifik browser og server. IE's grænse for URL-længde er 2083 bytes (2K+35). For andre browsere som Netscape, Firefox osv. er der ingen teoretisk længdegrænse, og dens grænse afhænger af operativsystemets understøttelse. [Ref. 1]
3) "Variable længdeparametre sendes via URL" betyder faktisk, at GET-metoden bruges, når formularen indsendes, ikke POST-metoden. Det, der forårsager denne potentielle fejl, er brugen af GET-metoden til at indsende formulardata. Fordi GET-metoden sender dataene i URL'en videre til serveren til behandling.
4) Bemærk, at denne grænse er hele URL-længden, ikke kun din parameterværdi datalængde.
5) Da det er IE's grænse for URL-længde, har både GET-metoden og POST-metoden denne begrænsning.
(Se venligst det relaterede dokument for detaljer om GET- og POST-metoderne i FORMULAR [Ref. 2])
Anbefalinger:
1) Forstå det miljø, applikationen er placeret i, såsom browser- og servermiljøet i webapplikationen, og forstå dens specifikke parameterbegrænsninger.
2) Brug POST-metoden så meget som muligt til at indsende komplekse data. Bemærk: Når FORM ikke skriver metodeattributtet, er standarden at bruge GET-metoden.
Konklusion (skriv til tjekliste):
Når du indsender data med GET-metoden, skal du tage højde for URL-længdegrænsen på 2083 bytes i IE-miljøet.
2. Den anden:
1) Teoretisk set har POST ingen størrelsesbegrænsning. HTTP-protokolspecifikationen har heller ingen størrelsesbegrænsning.
2) "Der er en størrelsesgrænse på 128K for POST-data" er ikke nøjagtigt nok, der er ingen grænse for POST-data, og processorens processorkraft spiller en begrænsende rolle.
3) For ASP-programmer er der en datalængdegrænse på 100K, når Request-objektet behandler hvert formularfelt. Men med Request.BinaryRead findes der ingen sådan begrænsning. For løsninger, der kræver behandling af mere end 100.000 formulardomænedata, henvises til [Ref. 3] nedenfor.
4) I forlængelse heraf har Microsoft for IIS 6.0 øget restriktionerne af sikkerhedsmæssige årsager [Ref. 4]. Vi skal også være opmærksomme på:
IIS 6.0 er som standard maksimalt 200 KB ASP POST-data, og grænsen er 100 KB pr. formularfelt.
Standardstørrelsen på IIS 6.0 uploadfiler er 4MB.
IIS 6.0 har som standard en maksimal anmodningsheader på 16KB.
Disse begrænsninger var ikke tilgængelige før IIS 6.0.
Anbefalinger:
1) At kende standardindstillingerne for kørende miljø vil hjælpe dig med at designe og hurtigt løse problemer, der opstår.
2) Serverversionen bør overvejes. Hver version af IIS har forskellige standardindstillinger for disse parametre, så hvis nødvendigt, find information og udarbel en sammenligningstabel. På denne måde er der en reference til udvikling og test.
3) Disse begrænsninger i IIS 6.0 er faktisk bare standardindstillingerne, og du kan ændre dem i selve applikationsmiljøet.
I WINNT/system32/inetsrv/MetaBase.xml er standarddefinitionen:
AspBufferingLimit="4194304" svarer til den maksimale størrelse af den uploadede fil
AspMaxRequestEntityAllowed="204800" svarer til den maksimale mængde data i POST
...
Konklusion (skriv til tjekliste):
Når du bruger ASP, skal du tage højde for, at POST-formularen har en grænse på 100KB pr. felt til generel læsebehandling. Overvej om du skal bruge Request.Binary.
|
Opslået på 08/03/2018 10.18.07
|
|
|
|
