|
|
Postitatud 08.03.2018 10:18:07
|
|
|
|
1. Probleemi põhjused
Veastatistika lisas "Post-Release Problems" pärast projekti avaldamist on järgmised:
Kogemuste kogumisena lisatakse need probleemid, põhjused ja lahendused kontrollnimekirja, seejärel:
Esimene küsimus: kas URL-i parameetri ülemine piir on täpne viide? Mis on ülemine piir?
Teine küsimus: Miks on POST-i ajal andmete piirang? Kas piir on 128K?
2. Probleemianalüüs
1. Esimene:
1) URL-is ei ole parameetrite ülemist piiri. Probleem on tegelikult selles, et IE-l on URL-ide pikkuse piirang.
2) HTTP protokolli spetsifikatsioon ei piira ka URL-i pikkust. See piirang on piirang, mille kehtestab konkreetne brauser ja server. IE URL-i pikkuse piirang on 2083 baiti (2K+35). Teistel brauseritel nagu Netscape, FireFox jne puudub teoreetiline pikkuse piirang ning selle piirang sõltub operatsioonisüsteemi toest. [Viide 1]
3) "Muutuva pikkusega parameetrid edastatakse URL-i kaudu" tähendab tegelikult, et vormi esitamisel kasutatakse GET meetodit, mitte POST meetodit. Selle võimaliku vea põhjustab GET meetodi kasutamine vormiandmete esitamiseks. Sest GET meetod edastab URL-i andmed serverile töötlemiseks.
4) Pane tähele, et see piirang hõlmab kogu URL-i pikkust, mitte ainult sinu parameetri väärtust andmepikkust.
5) Kuna see on IE URL-i pikkuse piirang, on nii GET meetodil kui ka POST meetodil see piirang.
(Palun vaadake vastavat dokumenti, et saada teavet FORM [Viide 2] GET ja POST meetodite kohta)
Soovitused:
1) Mõista keskkonda, kus rakendus asub, näiteks veebirakenduse brauseri ja serveri keskkond, ning mõista selle spetsiifilisi parameetrite piiranguid.
2) Kasutage POST meetodit nii palju kui võimalik keeruliste andmete esitamiseks. Märkus: Kui FORM ei kirjuta meetodi atribuuti, kasutatakse vaikimisi GET meetodit.
Kokkuvõte (kirjuta kontrollnimekirja):
Andmete esitamisel GET meetodiga tuleb arvestada URL-i pikkuse piiranguga 2083 baiti IE keskkonnas.
2. Teine:
1) Teoreetiliselt pole POST-il suurusepiirangut. HTTP protokolli spetsifikatsioonil puudub samuti suuruse piirang.
2) "POST-andmetel on suurusepiirang 128K" ei ole piisavalt täpne, POST-andmetel pole piirangut ning serveri protsessori arvutusvõimsus mängib piiravat rolli.
3) ASP programmide puhul on 100K andmepikkuse piirang, kui Request objekt töötleb iga vormivälja. Aga Request.BinaryRead puhul sellist piirangut ei ole. Lahenduste puhul, mis vajavad üle 100K vormidomeeni andmete töötlemise, palun vaadake allolevat [Viide 3].
4) Laiendatult on Microsoft IIS 6.0 puhul turvalisuse kaalutlustel piiranguid suurendanud [Viide 4]. Samuti peame tähelepanu pöörama:
IIS 6.0 vaikimisi kasutab maksimaalselt 200 KB ASP POST andmeid ning piirang on 100 KB vormivälja kohta.
IIS 6.0 üleslaadimisfailide vaikimisi suurus on 4MB.
IIS 6.0 vaikimisi kasutab maksimaalset päringupäist 16KB.
Need piirangud puudusid enne IIS 6.0 versiooni.
Soovitused:
1) Jooksukeskkonna vaikimisi seadete tundmine aitab sul kiiresti disainida ja lahendada tekkivaid probleeme.
2) Serveri versiooni tuleks kaaluda. Igal IIS-i versioonil on nende parameetrite jaoks erinevad vaikeseaded, seega vajadusel leia infot ja koosta võrdlustabel. Nii on olemas viide arenduseks ja testimiseks.
3) Need IIS 6.0 piirangud on tegelikult vaid vaikimisi seaded ja neid saab rakenduskeskkonnas muuta.
WINNT/system32/inetsrv/MetaBase.xml definitsioonis on vaikimisi definitsioon:
AspBufferingLimit="4194304" vastab üleslaaditud faili maksimaalsele suurusele
AspMaxRequestEntityAllowed="204800" vastab POST-i maksimaalsele andmemahule
...
Kokkuvõte (kirjuta kontrollnimekirja):
ASP kasutamisel tuleb arvestada, et POST-vormil on piirang 100KB ühe välja kohta üldiseks lugemisprotsessiks. Mõtle, kas kasutada Request.Binary.
|
Eelmine:asp.net mvc seab vormipostituse nii, et HTML esitamine lubabJärgmine:System.Linq.Dynamic
|
