1. Ongelman syyt
Julkaisun jälkeisten bugitilastojen liitteessä "Post-Release Problems" projektin julkaisun jälkeen on:
Kokemuksen kertymisenä nämä ongelmat, syyt ja ratkaisut sisällytetään tarkistuslistalle, sitten:
Ensimmäinen kysymys: Onko URL-parametrin yläraja tarkka viittaus? Mikä on yläraja?
Toinen kysymys: Miksi POSTissa on rajoitus datalle? Onko raja 128K?
2. Ongelman analyysi
1. Ensimmäinen:
1) URL-osoitteessa ei ole ylärajaa parametreille. Ongelma on itse asiassa siinä, että IE:llä on URL-osoitteiden pituusrajoitus.
2) HTTP-protokollan määrittely ei myöskään rajoita URL-osoitteen pituutta. Tämä rajoitus on rajoitus, jonka asettaa tietty selain ja palvelin. IE:n URL-pituuden raja on 2083 tavua (2K+35). Muille selaimille, kuten Netscapelle, FireFoxille jne., ei ole teoreettista pituusrajoitusta, ja sen rajoitus riippuu käyttöjärjestelmän tuesta. [Viite 1]
3) "Muuttuvan pituiset parametrit välitetään URL-osoitteen kautta" tarkoittaa itse asiassa sitä, että lomakkeen lähettämisessä käytetään GET-menetelmää, ei POST-menetelmää. Tämän mahdollisen virheen syynä on GET-menetelmän käyttö lomakkeen tietojen lähettämiseen. Koska GET-metodi välittää URL-osoitteen tiedot palvelimelle käsiteltäväksi.
4) Huomaa, että tämä raja koskee koko URL-osoitteen pituutta, ei pelkästään parametrin arvon datan pituutta.
5) Koska IE:n URL-pituusrajoitus on kyseessä, sekä GET-metodilla että POST-metodilla on tämä rajoitus.
(Katso asiaankuuluvasta asiakirjasta lisätietoja FORMin GET- ja POST-menetelmistä [Viite 2])
Suositukset:
1) Ymmärrä ympäristö, jossa sovellus sijaitsee, kuten web-sovelluksen selain- ja palvelinympäristö, sekä sen erityiset parametrirajoitukset.
2) Käytä POST-menetelmää mahdollisimman paljon monimutkaisten tietojen lähettämiseen. Huomautus: Kun FORM ei kirjoita metodin attribuuttia, oletuksena käytetään GET-metodia.
Yhteenveto (kirjoita tarkistuslistalle):
Kun lähetät dataa GET-menetelmällä, sinun tulee ottaa huomioon URL-pituusrajoitus 2083 tavua IE-ympäristössä.
2. Toinen:
1) Teoriassa POST:lla ei ole kokorajoitusta. HTTP-protokollan määrittelyssä ei myöskään ole kokorajoitusta.
2) "POST-datalle on koon rajoitus 128K" ei ole tarpeeksi tarkka, POST-datalle ei ole rajoitusta, ja palvelimen prosessorin prosessointiteho on rajoittava.
3) ASP-ohjelmilla on 100K datan pituusrajoitus, kun Request-objekti käsittelee jokaisen lomakekentän. Mutta Request.BinaryReadissa tällaista rajoitusta ei ole. Ratkaisuista, jotka vaativat yli 100 000 lomakedomain-datan käsittelyä, katso alla olevaan [Viite 3].
4) Laajennuksena Microsoft on lisännyt rajoituksia IIS 6.0:ssa turvallisuussyistä [Viite 4]. Meidän on myös kiinnitettävä huomiota:
IIS 6.0 oletuksena on enintään 200 KB ASP POST -dataa, ja raja on 100 KB per lomakekenttä.
IIS 6.0 -lataustiedostojen oletuskoko on 4MB.
IIS 6.0 oletuksena on enimmäispyyntöotsikko 16KB.
Nämä rajoitukset eivät olleet saatavilla ennen IIS 6.0:aa.
Suositukset:
1) Juoksuympäristön oletusasetusten tunteminen auttaa sinua suunnittelemaan ja ratkaisemaan nopeasti ongelmia, joita ilmenee.
2) Palvelinversio tulisi harkita. Jokaisessa IIS-versiossa on näille parametreille erilaiset oletusasetukset, joten tarvittaessa etsi tietoa ja laadi vertailutaulukko. Näin on olemassa viite kehitykseen ja testaukseen.
3) Nämä IIS 6.0:n rajoitukset ovat itse asiassa vain oletusasetuksia, ja niitä voi muokata varsinaisessa sovellusympäristössä.
WINNT/system32/inetsrv/MetaBase.xml:ssa oletusmääritelmä on:
AspBufferingLimit="4194304" vastaa ladatun tiedoston maksimikokoa
AspMaxRequestEntityAllowed="204800" vastaa POSTin maksimidatamäärää
...
Yhteenveto (kirjoita tarkistuslistalle):
Kun käytät ASP:tä, sinun tulee ottaa huomioon, että POST-lomakkeella on 100KB rajoitus per kenttä yleistä lukukäsittelyä varten. Harkitse, käytätkö Request.Binaryä.
|
Julkaistu 8.3.2018 10.18.07
|
|
|
|
