1. Årsaker til problemet
I vedlegget "Post-Release Problems" med feilstatistikken etter lansering av et prosjekt, finnes:
Som en erfaringsakkumulering vil disse problemene, årsakene og løsningene bli inkludert i sjekklisten, og deretter:
Det første spørsmålet: Er øvre grense for URL-parameteren nøyaktig referanse? Hva er øvre grense?
Andre spørsmål: Hvorfor er det en grense for data når man bruker POST? Er grensen 128 000?
2. Problemanalyse
1. Den første:
1) Det finnes ingen øvre grense for parametere i URL-en. Problemet er faktisk at IE har en lengdebegrensning på URL-er.
2) HTTP-protokollspesifikasjonen begrenser heller ikke lengden på URL-en. Denne begrensningen er en begrensning pålagt av en spesifikk nettleser og server. IEs grense for URL-lengde er 2083 byte (2K+35). For andre nettlesere som Netscape, Firefox osv. finnes det ingen teoretisk lengdegrense, og grensen avhenger av hvordan operativsystemet støtter. [Ref. 1]
3) «Variabel-lengde parametere sendes via URL» betyr faktisk at GET-metoden brukes ved innsending av skjemaet, ikke POST-metoden. Det som forårsaker denne potensielle feilen er bruken av GET-metoden for å sende inn skjemadata. Fordi GET-metoden sender dataene i URL-en til serveren for behandling.
4) Merk at denne grensen er hele URL-lengden, ikke bare parameterverdiens datalengde.
5) Siden det er IEs grense for URL-lengde, har både GET-metoden og POST-metoden denne begrensningen.
(Se det tilhørende dokumentet for detaljer om GET- og POST-metodene i FORM [Ref. 2])
Anbefalinger:
1) Forstå miljøet applikasjonen befinner seg i, som nettleser- og servermiljøet til webapplikasjonen, og forstå dens spesifikke parameterbegrensninger.
2) Bruk POST-metoden så mye som mulig for å sende inn komplekse data. Merk: Når FORM ikke skriver metodeattributtet, er standarden å bruke GET-metoden.
Konklusjon (skriv til sjekklisten):
Når du sender inn data med GET-metoden, må du ta hensyn til URL-lengdegrensen på 2083 byte i IE-miljøet.
2. Den andre:
1) Teoretisk sett har POST ingen størrelsesgrense. HTTP-protokollspesifikasjonen har heller ingen størrelsesgrense.
2) «Det er en størrelsesgrense på 128K for POST-data» er ikke nøyaktig nok, det finnes ingen grense for POST-data, og prosessorkraften til serverens prosessor spiller en begrensende rolle.
3) For ASP-programmer er det en datalengde på 100K når Request-objektet behandler hvert skjemafelt. Men med Request.BinaryRead finnes det ingen slik begrensning. For løsninger som krever behandling av mer enn 100 000 skjema domenedata, vennligst se [Ref. 3] nedenfor.
4) I forlengelsen, for IIS 6.0, har Microsoft økt restriksjonene av sikkerhetsgrunner [Ref. 4]. Vi må også være oppmerksomme på:
IIS 6.0 har som standard maksimalt 200 KB ASP POST-data, og grensen er 100 KB per skjemafelt.
Standardstørrelsen på IIS 6.0-opplastingsfiler er 4MB.
IIS 6.0 har som standard en maksimal forespørselsheader på 16KB.
Disse begrensningene var ikke tilgjengelige før IIS 6.0.
Anbefalinger:
1) Å kjenne standardinnstillingene i kjøremiljøet vil hjelpe deg å designe og raskt løse problemer som oppstår.
2) Serverversjonen bør vurderes. Hver versjon av IIS har ulike standardinnstillinger for disse parameterne, så om nødvendig, finn informasjon og lag en sammenligningstabell. På denne måten finnes det en referanse for utvikling og testing.
3) Disse begrensningene i IIS 6.0 er egentlig bare standardinnstillingene, og du kan endre dem i selve applikasjonsmiljøet.
I WINNT/system32/inetsrv/MetaBase.xml er standarddefinisjonen:
AspBufferingLimit="4194304" tilsvarer maksimal størrelse på den opplastede filen
AspMaxRequestEntityAllowed="204800" tilsvarer maksimal mengde data i POST
...
Konklusjon (skriv til sjekklisten):
Når du bruker ASP, må du ta i betraktning at POST-skjemaet har en grense på 100KB per felt for generell lesebehandling. Vurder om du skal bruke Request.Binary.
|
Publisert på 08.03.2018 10:18:07
|
|
|
|
