1. Orsaker till problemet
I bilagan "Post-Release Problems" med buggstatistiken efter att ett projekt släppts finns det:
Som en erfarenhetsackumulering kommer dessa problem, orsaker och lösningar att inkluderas i checklistan, och sedan:
Den första frågan: Är den övre gränsen för URL-parametern korrekt referens? Vad är den övre gränsen?
Andra frågan: Varför finns det en databegränsning när man använder POST? Är gränsen 128 000?
2. Problemanalys
1. Den första:
1) Det finns ingen övre gräns för parametrar i URL:en. Problemet är faktiskt att IE har en längdbegränsning på URL:er.
2) HTTP-protokollspecifikationen begränsar inte heller URL:ens längd. Denna begränsning är en begränsning som påtvingas av en specifik webbläsare och server. IE:s gräns för URL-längd är 2083 byte (2K+35). För andra webbläsare som Netscape, Firefox med flera finns det ingen teoretisk längdgräns, och dess gräns beror på operativsystemets stöd. [Ref. 1]
3) "Variabel-längdsparametrar skickas via URL" betyder faktiskt att GET-metoden används vid inlämning av formuläret, inte POST-metoden. Det som orsakar detta potentiella fel är användningen av GET-metoden för att skicka in formulärdata. Eftersom GET-metoden skickar datan i URL:en till servern för bearbetning.
4) Observera att denna gräns är hela URL-längden, inte bara din parametervärdesdata.
5) Eftersom det är IE:s gräns för URL-längd har både GET-metoden och POST-metoden denna begränsning.
(Vänligen se det relaterade dokumentet för detaljer om GET- och POST-metoderna i FORMULÄR [Ref. 2])
Rekommendationer:
1) Förstå miljön där applikationen är placerad, såsom webbläsar- och servermiljön i webbapplikationen, och förstå dess specifika parameterbegränsningar.
2) Använd POST-metoden så mycket som möjligt för att skicka in komplex data. Notera: När FORM inte skriver metodattributet är standarden att använda GET-metoden.
Slutsats (skriv till checklistan):
När du skickar in data med GET-metoden behöver du ta hänsyn till URL-längdsgränsen på 2083 byte i IE-miljön.
2. Den andra:
1) Teoretiskt sett har POST ingen storleksgräns. HTTP-protokollspecifikationen har heller ingen storleksgräns.
2) "Det finns en storleksgräns på 128K för POST-data" är inte tillräckligt exakt, det finns ingen gräns för POST-data, och processorkraften hos serverns processor spelar en begränsande roll.
3) För ASP-program finns en datalängdsgräns på 100K när Request-objektet behandlar varje formulärfält. Men med Request.BinaryRead finns ingen sådan begränsning. För lösningar som kräver bearbetning av mer än 100 000 formulärdomändata, se [Ref. 3] nedan.
4) Därigenom har Microsoft för IIS 6.0 ökat restriktionerna av säkerhetsskäl [Ref. 4]. Vi måste också uppmärksamma på:
IIS 6.0 är som standard maximalt 200 KB ASP POST-data, och gränsen är 100 KB per formulärfält.
Standardstorleken på IIS 6.0-uppladdningsfiler är 4 MB.
IIS 6.0 har som standard en maximal begäran på 16KB.
Dessa begränsningar fanns inte före IIS 6.0.
Rekommendationer:
1) Att känna till standardinställningarna för den körande miljön hjälper dig att designa och snabbt lösa problem som uppstår.
2) Serverversionen bör beaktas. Varje version av IIS har olika standardinställningar för dessa parametrar, så om det behövs, hitta information och sammanställ en jämförelsetabell. På detta sätt finns en referens för utveckling och testning.
3) Dessa begränsningar i IIS 6.0 är egentligen bara dess standardinställningar, och du kan ändra dem i den faktiska applikationsmiljön.
I WINNT/system32/inetsrv/MetaBase.xml är standarddefinitionen:
AspBufferingLimit="4194304" motsvarar den maximala storleken på den uppladdade filen
AspMaxRequestEntityAllowed="204800" motsvarar den maximala mängden data i POST
...
Slutsats (skriv till checklistan):
När du använder ASP måste du tänka på att POST-formuläret har en gräns på 100 KB per fält för allmän läsbehandling. Fundera på om du ska använda Request.Binary.
|
Publicerad på 2018-03-08 10:18:07
|
|
|
|
