Daily Archives: 2009.01.7. 14:50

Keresőbarát URL-ek IIS 7 alatt

Korábban már írtam az IIS 7-ben található request filtering komponensről, amely segítségével a bejövő URL-eket lehet szétszabdalni és bizonyos szempontok szerint engedélyezni vagy tiltani a kérés feldolgozását. Van egy másik eset, amikor a bejövő URL-t kell felparszolni, ez pedig virtuális URL-ek használatakor fordul elő. Vagyis amikor article.aspx?id=123 helyett barátságosabb, például article/123 formátumú címet szeretnénk használni. Erre szolgál az IIS 7-hez letölthető URL Rewrite Module komponens is.

A funkció egyébként nem új, az Apache mod_rewrite komponense már régóta tudja, de IIS alatt eddig csak fizetős komponenssel vagy egy kis ASP.NET programozással lehetett ezt a feladatot megoldani. ASP.NET-ben írtuk meg egyébként a korábbi devPortal és az MSDN Kompetencia Központ adatbázis alapú virtuális URL mappingjét is…

Szerencsére most már mindez megy kódolás nélkül is, csak le kell hozzá tölteni az ingyenes kiegészítést, ami valószínűleg az SP2-től már az IIS 7 része lesz. Az URL Rewrite modul segítségével a bejövő kérésnek gyakorlatilag bármely részére megfogalmazhatunk illeszkedési feltételt: az URL-re, a HTTP fejléc mezőkre, a query stringre vagy akár szerver változókra. Az illeszkedési feltételt megadhatjuk egyszerű wildcardos vagy reguláis kifejezés formájában. Ha a modulnak sikerül az általunk megadott szabályt ráillesztenie egy bejövő kérésre, a szabályban megadott címre irányítja át a kérést.

A dologban nem csak az a szép, hogy minden beállításunk a web.configban együtt utazik az alkalmazással, hanem az is, hogy az IIS Managerben a modulhoz tartozó grafikus felületen számos segítséget kapunk a szabályok szerkesztéséhez. Például sablonok és tesztelési felület is rendelkezésre áll.

Például valószínűleg sokan írtunk már le valami hasonlót:

    <asp:HyperLink runat="server" 
Text='<%# Eval("Title") %>' NavigateUrl='<%# Eval("ID", "Article.aspx?id={0}") %>' />

Sokkal szebb lenne, ha ezt írnánk:

    <asp:HyperLink runat="server" 
Text='<%# Eval("Title") %>' NavigateUrl='<%# Eval("ID", "Article/{0}") %>' />

Ahhoz, hogy ez működjön, persze kell egy kicsit varázsolni az IIS Managerben. Az URL Rewrite modulban kattintsunk az Add Rules… gombra, majd válasszuk a User friendly URL sablont: URL Rewrite: új szabály létrehozása

Adjuk meg azt az URL-t, amivel most működik az alkalmazásunk és válasszuk ki azt, ahogy a felhasználóknak láttatni szeretnénk a címet. Itt érdemes arra figyelni, hogy bár címként a szerver nevét is meg kell adni, az illesztési mintában és az átírt címben erre nincs szükség. Szintén érdemes kihagyni az alkalmazásunk virtuális mappáját.

URL Rewrite: új szabály létrehozása varázslóval

Ha az alsó Create corresponding redirect rule jelölőnégyzetet bekattintjuk, akkor a nem kívánatos query stringes címről is át lesznek irányítva a kérések a barátságos címre.

A varázsló leokézása után a megjelenő új szabályra duplán kattintva módosíthatjuk azt:

URL Rewrite: szabály szerkesztéseJó tudni, hogy itt válthatunk át reguláris kifejezésekről egyszerű wildcardos keresésre, illetve itt található a Test pattern funkció is, ahol kipróbálhatjuk, hogy a mintánk jól működik-e az általunk megadott URL-re.

A sok kattintgatás eredménye a web.configban található:

    <system.webServer>
        <rewrite>
            <rules>
                <clear />
                <rule name="RewriteUserFriendlyURL1" stopProcessing="true">
                    <match url="^article/([^/]+)/?$" />
                    <conditions>
                        <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
                        <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
                    </conditions>
                    <action type="Rewrite" url="article.aspx?id={R:1}" />
                </rule>
            </rules>
        </rewrite>
    </system.webServer>

Ennyi az egész, máris működik! Persze csak akkor, ha mindent jól csináltunk. Ha nem, akkor 404 – Not Found hibaüzenetet fogunk kapni. Akkor nincs más hátra, elő kell kapnunk az IIS 7 Failed Request Tracing szolgáltatását és meg kell néznünk, hogy az URL Rewrite modul működik-e vagy sem. Vegyünk fel egy új tracing szabályt a 404-es hibakódra és a trace providerek közül válasszuk ki a Rewrite komponents:

URL Rewrite: failed request tracing

Kérjük le az oldalt, majd nézzük meg a logot a C:inetpublogsFailedReqLogFilesW3SVC1 mappában:

URL Rewrite: failed request tracing log

A PATTERN_MATCH és RULE_EVALUATION_END szekciókban figyeljük a Matched és a Succeeded értékeket. Ha false, akkor bizony valamit nem jól csináltunk. Én így jöttem rá, hogy az alkalmazás mappájának nevére (a fenti képen UrlRewriteSample) nincs szükség…

Ez persze csak egy alkalmazása az URL Rewrite modulnak…

A cikkhez tartozó példa kód letölthető innen.

 

Advertisements

Az IIS log kigazolása

Jól működő weboldal esetén az ember ritkán nézi a webszerver naplóját, hiszen a durva hibák úgyis megjelennek a Windows eseménynaplójában, a forgalmi statisztikákat pedig a Google Analytics adja közvetlenül. Ha viszont mégis bele kell kukkantani, jön az elszörnyedés, mi ez a sok szemét és hova bújt a lényeg? Íme néhány tipp a webkiszolgáló naplójának tisztán tartásához.

Aranyszabály: amire soha nem leszünk kíváncsiak, azt ne naplózzuk!

A gyakorlatban ez általában azt jelenti, hogy nem érdekelnek a .jpg, .gif., .png, .js és .css fájlokra érkező HTTP kérések. Érdekelnek a letöltések, az oldal lekérések, hogy a böngészők megtalálták-e a favicon.ico fájlunkat, de képek, szkriptek és stíluslapok lekérését még soha nem akartam visszakeresni. Egy fotóblog vagy galéria oldalnál biztosan akarnám, olyanom viszont nincs.

A naplózást IIS6-ban ki lehet kapcsolni a Log visits kapcsolóval a webkiszolgáló minden szintjén, a beállítás öröklődik lefelé:

IIS 6: Log visits

IIS 7 esetén azonban a grafikus felületen nem fogunk ilyen nevű kapcsolót találni. Sőt, amikor először megnézzük egy mappa vagy webhely Logging beállításait minden vezérlő kikapcsolt állapotban lesz, a lényeg azonban ott virít jobb oldalon:

IIS 7: Disable logging

Ha itt kikapcsoljuk a loggolást, ez fog beíródni az applicationHost.config fájlba:

    <location path="Default Web Site/images">
        <system.webServer>
            <httpLogging dontLog="true" />
        </system.webServer>
    </location>

Látható, hogy a lényeg a httpLogging elem, a célra tartást pedig a location elemmel végezhetjük el. Ha már ezt tudjuk, takarítsuk el az ASP.NET .axd handlereit a logból. Írjuk például ezt a saját alkalmazásunk gyökér web.configjába:

    <?xml version="1.0" encoding="utf-8"?>
    <configuration>

        <!-- Szokásos részek... -->

        <location path="ScriptResource.axd">
            <system.webServer>
                <httpLogging dontLog="true" />
            </system.webServer>
        </location>
        
        <location path="WebResource.axd">
            <system.webServer>
                <httpLogging dontLog="true" />
            </system.webServer>
        </location>
    </configuration>

Megsúgom, ebből baj lesz. Mégpedig azért, mert a httpLogging szekció alapértelmezés szerint nincs delegálva, tehát csak az applicationHost.config fájlban szerkeszthető. A jutalmunk egy szép HTTP Error 500.19:

The requested page cannot be accessed because the related configuration data for the page is invalid.

This configuration section cannot be used at this path. This happens when the section is locked at a parent level. Locking is either by default (overrideModeDefault="Deny"), or set explicitly by a location tag with overrideMode="Deny" or the legacy allowOverride="false".

Ha hasonlóan a képek naplózását tiltjuk le, azt fogjuk tapasztalni, hogy az oldalaink betöltődnek, csak éppen a képek fognak hiányozni róluk.

Ha jól végiggondoltuk, hogy ezt a lehetőséget inkább a webhely gazdájának kezébe adnánk, irány a Feature Delegation az IIS Managerben, billentsük át a Logging sort Read/Write-ra:

IIS 7: Logging feature delegation

Ettől kezdve location tag nélkül is tehetünk web.config fájlokat például a css vagy images mappáinkba.

Sajnos a location nem ismerni a wildcardokat, nem tudjuk tehát egyszerűen kizárni a webhelyünkhöz tartozó összes .jpg fájlt. Ezért érdemes úgy szervezni a fájljainkat, hogy a naplózásból tiltandó fájlok egy mappában vagy annak almappáiban legyenek.

Az IIS 7-ben megtehetjük azt is, hogy csak a sikertelen kéréseket naplóztatjuk, azaz ahol a HTTP status code 400 vagy nagyobb. Ehhez a httpLogging szekcióban használjuk a selectiveLogging=”LogError” attribútumot.