ASP.NET ja URL rewrite
19.10.2007 | GunnarPeale sõbralikku vaibal käimist Microsoft Eestist kirjutan sündmuse jäädvustamiseks ühe tehnilises mõttes huvitava kande, kus kohtuvad ASP.NET ja SEO. Tegelikult leidsin ühe portsu huvitavat lugemist ja mõtlesin, et panen sellel teemal lõpuks oma mõttet, ideed ja nõuanded kirja.
"Ilusad" URL-id on siin blogis leidnud palju kajastust, kuid ASP.NET-i kontekstis vaid ühe korra. Seda siis ühte rewriter-it tutvustavad kandes URL rewrite ASP.NET jaoks. ASP.NET korral tõstatuvad analoogsed küsimused nagu muudel platvormidel, peamiselt see, et mis oleks parim lahendus.
Parim lahendus, ütlen kohe ära, sõltub paljuski sellest, mis võimalusi pakub server. Või õigemini, kui palju ISP vastu tuleb. Leidub neid, kes on väga jäigad, kuid on ka neid, kes lahkesti abistavad.
ISAPI laiendus
ISAPI laiendused on võimsaimad, sest võimaldavad ilma piiranguteta mängida edukalt järgi Apache mooduli mod_rewrite poolt pakutavat. Probleemiks võib osutuda see, et ISAPI laiendusi ei saa serverile lisada kõik kasutajad - selleks on vaja administraatorit.
URL-id võivad olla seega suvalisel kujul. Näiteks:
http://minudomeen/olematufail.suva.laiend
ISAPI laiendusi on saadaval igasuguseid, leidub nii tasulisi kui ka tasuta laiendusi. Minu senise kogemuse põhjal on see kõige probleemivabam lähenemine. Aga, kes arvab teisiti, kirjutagu omad kogemused ja mõttekäigud selle kande kommentaaridesse kindlasti üles.
HTTP moodulid
Teine võimalus on kasutada HTTP mooduleid. Moodulid võimaldavad kontrollida sisenevaid päringuid ning võtta siis ette päringule vastav toiming. Näiteks serveerida vastuseks mõni fail või hoopis veateade. HTTP moodulite juures võib tekkida probleeme sellega, et need töötavad ainult .aspx laiendiga failide korral.
Tegelikult saab teha ka nii, et HTTP moodul lastakse käima kõikide pöördumiste korral, mis tehakse näiliselt failidele. Selleks tuleb IIS-i määrangutes paika panna, et kõiki päringuid failidele töötleb ASP.NET-i ISAPI laiendus. Puuduseks on see, et pöördumised kataloogidele - nii nendele, mis on olemas, kui ka nendele, mida pole, lähevad HTTP moodulist mööda.
URL-id on seega kujul:
HTTP moodulite kasutamist olen proovinud, kuid kerge on sattuda küllaltki raskesti lahendatavate probleemide otsa. Suhteliselt segaseks jäi kunagi mobiilide jaoks portaali ehitades see, miks mõnel korral ikoonide laadimine HTTP mooduli kasutamisel serveri CPU tükiks ajaks 100% peale tõmbas. Mingile kindlale korrapärale see ei allunud, samuti ei suutnud ma seda käitumist reprodutseerida teiste serverite peal.
Päringute suunamine läbi vaikimisi faili
Kolmas võimalus jääb eelmise kahe vahele mõnes mõttes. Ühelt poolt saab mängida maha kataloogidele ja failidele mõlemale pöördumisi. Teisalt aga peab URL-i sees olema kindlasti olemas .aspx fail, mis pöördumise ära töötleb. ASP.NET on selles mõttes nö. first shot URL-idega, sest pöördumise saab esimene fail, mis teele ette jääb.
URL-id võivad olla kujul:
http://minudomeen/default.aspx/fail.laiend
Seejuures pole oluline, kas vastav fail või kataloog on olemas.
See lähenemine oli kunagise mobiilide projekti juures parim. Tänapäeva mõttes vanemad WAP-toega telefonid ei tunne näiteks allalaaditavaid pildifaile ära, kui pildil pole neile tuntud laiend. Content-Disposition siinkohal ei aidanud, sest paljud mobiilide brauserid ignoreerisid seda. Seevastu näiteks URL kujul
[html]http://minudomeen/default.aspx/wallpapers/10329.gif[/http]
toimis kenasti. Default.aspx töötles ära pöördumise ning mobiiltelefon sai kenasti kätte õige faili nime. Neid jõudluse probleeme, mis esinesid HTTP moodulite kasutamisega, selle lähenemise korral ei esinenud ning see oli antud serveri peal lihtsaim ja stabiilseim lahendus.
Päringute töötlemine viga 404 failis
Neljas võimalus on kasutada faili, mida server näitab siis, kui küsitakse faili või kataloogi, mida ei leita. Serveri konfiguratsioonis tuleb määrata vastava .aspx faili nimi ning antud fail peab siis pöördumise ära töötlema.
Õnnestunud pöördumise korral peab selles failis muutma HTTP staatuse koodi, et brauserini jõuaks 404 asemel 202. Vastasel korral ei saa ei brauserid ega kasutajad aru, et tegemist oli õnnestunud pöördumisega. Samuti ei tohi õnnestunud pöördumiste korral sattuda serveri logidesse kandeid, kus väidetakse, et pöördumine lõppes veaga.
Selle lahenduse vastu räägivad probleemid, millesse jooksid inimesed kokkuvõtte osas toodud viidetel.
Kokkuvõtteks
Kõikidel neid meetoditel on omad plussid ja miinused. Need võtab väga hästi kokku Nathanael Jones oma blogi kandes Resolution. HTTP moodulite kasutamise kohta annab hea ülevaate Code Project-i artikkel Using HttpModules with URL Re-writing to Handle Fake Directory Requests. Probleeme aitab viimase artikli koodi juures lahendada MSDN Library artikkel URL Rewriting in ASP.NET. Mina jäin kõige enam rahule ühe ISAPI laiendusega ning omal ajal töötas väga kenasti ka päringute töötlemine viga 404 failis.