2010. január havi bejegyzések

Az IIS 7.0 szkriptelése PowerShellből

Az IIS 7.0 szkriptelése PowerShellből A Windows PowerShell Snap-in for IIS 7.0 ingyenesen letölthető kiegészítés, melynek segítségével közvetlenül PowerShell parancssorból kezelhetjük az IIS 7.0 konfigurációs beállításait, és futási idejű adatokat kérdezhetünk le a webkiszolgálótól. A snap-in regisztrálása után webhelyek, alkalmazáskészletek, webalkalmazások, virtuális mappák, kérések, munkafolyamatok és .NET alkalmazástartományok létrehozása, törlése és tulajdonságaik módosítása elvégezhető PowerShellből.

A snap-in létrehoz egy IIS: “meghajtót”, amelyben a mappa hierarchiához hasonlóan navigálhatunk a az IIS objektumok között. Objektumok lekérdezéséhez a Get-Item, létrehozásához és törléséhez a New-Item és a Remove-Item commandleteket használhatjuk. Az objektumok tulajdonságai a Get-ItemProperty parancs segítségével kérdezhetőek le és a Set-ItemProperty parancs segítségével állíthatóak be.

Az IIS tetszőleges konfigurációs beállításai lekérdezhetőek és beállíthatóak a Get-WebConfiguration és Set-WebConfiguration, valamint a Get-WebConfigurationProperty és Set-WebConfigurationProperty commandletek segítségével. Az XML beállítások közé új elemet felvenni az Add-, törölni a Remove-WebConfigurationProperty segítségével lehet. Teljes szekció a Clear-WebConfiguration commandlettel törölhető.

Demó

A demóban bemutatjuk, hogyan használhatjuk a PowerShellt új webhelyek, alkalmazások és alkalmazáskészletek létrehozására és az IIS 7.0 konfigurációs beállításainak módosítására.

IIS 7.0 PowerShell provider demó - a demó megtekintéséhez kattints a képre.

Lejátszáshoz kattints a képre!

Letöltés: PowerShell.wmv (24:23, 131 MB)

Első lépések

Indítsuk el a Server Managert és telepítsük fel a Windows PowerShell nevű Feature-t, majd töltsük le és telepítsük a Windows PowerShell Snap-in for IIS 7.0-t. Indítsuk el a Start Menüből az IIS PowerShell Management Console programot vagy a standard PowerShell promptban regisztráljuk az IIS PowerShell bővítményt az alábbi parancs futtatásával:

  PS C:> & "$env:programfilesIISPowerShellProvideriisConsole.psc1"

Jó tudni

A snap-in által támogatott commandletek listája lekérdezhető az alábbi paranccsal:

  Get-Command –pssnapin IISProviderSnapIn

IIS 7.5

A Windows Server 2008 R2-ben megjelent IIS 7.5 már beépítetten tartalmaz PowerShell támogatást a webszerver objektumainak kezeléséhez. Itt az új architektúrának megfelelően nem snap-in, hanem PowerShell module fogja össze az IIS 7.5 kezelésére szolgáló commandleteket. A module betöltését az alábbi paranccsal végezhetjük el:

  Import-Module WebAdministration

A betöltött commandletek listáját pedig ezzel a paranccsal kérdezhetjük le:

  Get-Command –Module WebAdministration

További információk

 

Technorati-címkék: ,,,

Reklámok

Ethical Hacking bemutató a BME-n

Ethical hacking Március elején hivatalos Ethical Hacking képzés indul a BME-n az Automatizálási és Alkalmazott Informatikai Tanszék és az EC-Council hazai képviselője, a NetAcademia Oktatóközpont közös szervezésében.

Hamarosan lesz egy bemutató a képzésből – gyere el!
Ha érdekel az informatikai biztonság egyik legizgalmasabb ága, az etikus hekkelés, gyere el Te is a képzésbemutatóra! Hekkelésekkel fogjuk demonstrálni, miért fontos/érdemes ezzel a területtel foglalkozni, milyen előnyöket jelent a CEH (Certified Ethical Hacker) minősítés megszerzése, illetve megtudhatsz minden részletet a képzés elvégzésével kapcsolatban.

A bemutató helyszíne és időpontja: 2010. február 9. kedd. 17:15 I.B.028. terem (BME Informatikai épület, Magyar Tudósok krt. 2.)

A NetAcademiát biztosan nem kell bemutatni: ők csinálták az Ördöglakat nevű hekkeres játékot, rendezik minden évben az Ethical Hacking konferenciát, az oktatás területén pedig olyan cégeknek tartanak biztonsági képzéseket, többek között Ethical Hacking képzést is, mint például a NATO.

Elindult az Ethical Hacking csoport a Facebookon (http://www.facebook.com/group.php?gid=424530330612). Ott már most fel lehet iratkozni a bemutatóra! Csatlakozz!

 

Technorati-címkék: ,

Legyen kereső az oldaladon

Annyira hozzá vagyunk szokva, hogy az interneten minden tartalom kereshető, hogy ma már nagyon amatőrnek tűnnek azok a weboldalak, ahol nem találunk keresődobozt. Szerencsére a Google AJAX Search API segítségével nagyon könnyen beépíthetjük a Google keresőjét a saját weboldalunkba.

A Google AJAX Search API egy JavaScriptes programozói felület, tehát ha tudunk a szerverünkön az egyik oldal forrásába JavaScript kódot írni, akkor használhatjuk, nem fog kelleni hozzá semmilyen szerver oldali technológia. Korábban létezett webszolgáltatás interfész is, azonban arról a SOAP API-ról most azt mondja a Google, hogy az csak egy “free experiment” volt limitációkkal, helyette inkább használjuk az AJAXos API-t, ami Firefox 1.5+, IE 6, Safari, Opera 9+ és Chrome böngészőkön támogatott. Hát rajta!

Az első lépés, hogy az oldalunk forráskódjában ki kell jelölnünk egy helyet, ahol a kereső meg fog jelenni. Egy gyakorlatilag egy div konténer, aminek a kezdeti tartalmát a késleltetve betöltött és megjelenített kereső felül fogja csapni (ha mégis megjelenik, akkor valamit rosszul csináltunk):

  <div id="searchPlaceholder">
    Betöltés, türelem...
  </div>

A kereső által renderelt tartalom az oldalunkon belül fog futni, div, table és form elemek kerülnek az oldalunkba (nincs szó iframe-ről). A generált layout minden szintjén találunk egy gsc- (gsc: Google Search Control) kezdetű CSS osztályt, ami segíthet a megjelenő tartalom megformázásában. Ezek közül a legkülső a gsc-control, ami alapértelmezés szerint 300px széles, ami többnyire nem éppen a legjobb helykihasználást eredményezi, húzzuk szét bátran:

  .gsc-control
  {
    width: 100%;
  }

Fontos, hogy mivel a kereső hoz magával CSS-t, azt felülcsapni csak akkor tudjuk, ha a kereső JavaScriptje utánra tesszük a saját CSS definíciónkat. Ennyit a dizájnról és a layoutról, térjünk át a kódra.

Az oldalban el kell helyeznünk egy script tag-et, ami letölti a kereső kódját a Google szerveréről:

  <script src="http://www.google.com/jsapi" type="text/javascript"></script>

Regisztrálhatunk egy AJAX API key-ért, amiről a gugli azt mondja, hogy teljesen opcionális, azonban ha valamit elrontanánk, ennek segítségével ők megpróbálhatják felvenni velünk a kapcsolatot. Ha nem szeretjük a nagy testvér effektust, akkor elég a fenti sor.

Ha már az oldal betöltésekor meg kívánjuk jeleníteni a keresőt, akkor a Google AJAX API Loader google.load metódusát kell használnunk (van lehetőség dinamikus betöltésre is JSONP stílusban). Ennek ez legegyszerűbb formája, a kód magáért beszél:

  google.load("search", "1");    
  function onGoogleLoaded()
  {      
    // Itt rakjuk majd össze a keresőt...
  }

  google.setOnLoadCallback(onGoogleLoaded);

A load metódusnak át kell adnunk, hogy melyik API-t (search, maps, feeds, language, gdata, earth, visualization, friendconnect, orkut) akarjuk használni, illetve hogy annak melyik verzióját. Harmadik paraméterként átadhatunk kapcsolókat, amivel elhagyhatjuk a CSS-t, a régi névtereket és magyar GUI-t kérhetünk:

  google.load("search", "1", { "nocss": true, "nooldnames": true, "language" : "hu" });    

Nincs más hátra, az onGoogleLoaded callback metódusunkban fel kell konfigurálnunk a keresőt, amihez létre kell hoznunk egy SearchControl objektumot:

  var ctrl = new google.search.SearchControl();

A ctrl objektumunkhoz hozzá kell adnunk ún. searcher objektumokat, amik a különböző forrásokban keresnek:

  ctrl.addSearcher( new google.search.WebSearch() );
  ctrl.addSearcher( new google.search.VideoSearch() );
  ctrl.addSearcher( new google.search.ImageSearch() );
  ctrl.addSearcher( new google.search.BlogSearch() ); 

Jelenítsük meg a SearchControlt a korábban létrehozott div-ben:

  ctrl.draw( document.getElementById( "searchPlaceholder" ) );

Ezzel sikeresen beemeltük a gugli keresőjét a saját oldalunkba, mindössze néhány sor kóddal, amin természetesen lehet finomítani. A legfontosabb, hogy valószínűleg csak a saját webhelyünkön belül szeretnénk keresni, ezért korlátozzuk a keresést. Ezt nem minden searcher objektum támogatja, de a leggyakrabban használt web és az image igen:

  var site = 'www.msdnkk.hu';

  var webSearch = new google.search.WebSearch();
  webSearch.setSiteRestriction(site);
  ctrl.addSearcher(webSearch);

  var imageSearch = new google.search.ImageSearch();
  imageSearch.setSiteRestriction(site);
  ctrl.addSearcher(imageSearch);

A következő, ami engem az alapértelmezett nézetben zavar, hogy kevés találat jelenik meg, kérjünk többet:

  ctrl.setResultSetSize( google.search.Search.LARGE_RESULTSET );

Ez viszont tapasztalatom szerint csak akkor működik, ha beállítjuk, hogy az egyes kategóriák sok találatot jelenítsenek meg:

  var searcherOptions = new google.search.SearcherOptions();
  searcherOptions.setExpandMode( google.search.SearchControl.EXPAND_MODE_OPEN );
  ctrl.addSearcher( webSearch, searcherOptions );

Ez így még elég szerencsétlen, mert nagyon hosszú lesz az oldal, alakítsuk át úgy, hogy a searcherek önálló füleken jelenjenek meg, ekkor nem is kell a SearcherOptions:

  var drawOptions = new google.search.DrawOptions();
  drawOptions.setDrawMode(google.search.SearchControl.DRAW_MODE_TABBED);
  ctrl.draw(document.getElementById("searchPlaceholder"), drawOptions);

A DrawOptions objektumra egyébként érdemes odafigyelni, lehetővé teszi például, hogy a keresődobozt leszakítsuk a találati listáról. Ehhez mindössze annyit kell tennünk, hogy létrehozunk egy másik div-et és meghívjuk a setSearchFormRoot metódust:

  drawOptions.setSearchFormRoot(document.getElementById("searchFormPlaceholder"));

A SearcherOptions objektum .setRoot metódusával mellesleg azt is meg lehet határozni, hogy az eredmények hol jelenjenek meg.

Sőt, akár megválhatunk a Google logós keresődoboztól, bármely saját input mezőnket felhasználhatjuk. Ha például van egy szövegdobozunk és egy gombunk:

  <input type="text" id="txtSearch" />
  <input type="button" value="Keress!" onclick="ctrl.execute();" />

Akkor DrawOptions segítségével azt is megadhatjuk, hogy ezt használja a kereső:

  drawOptions.setInput(document.getElementById("txtSearch"));

Számítsunk rá, hogy a kereső fel fog iratkozni ennek a szövegdoboznak az onkeyup és onpaste eseményeire, ami azért jó, mert az Enter kezelését is megoldja. A fenti kódból az is látszik, hogy saját kódunkból a keresést az execute metódus meghívásával tudjuk elindítani. Paraméter nélkül hívva az input mező tartalmára keres, de átadhatjuk neki a keresendő sztringet is.

Visszatérve a fülekre és a searcher objektumokra, természetesen megtehetjük azt is, hogy ugyanolyan típusú keresőből (pl. WebSearch) felteszünk kettőt két fülre, eltérő módon paraméterezve. Ebben az esetben célszerű használnunk a setUserDefinedLabel metódust, hogy egyedi nevet tudjunk adni a füleknek:

  var webSearch = new google.search.WebSearch();
  webSearch.setSiteRestriction(site);
  webSearch.setUserDefinedLabel("Ezen a webhelyen");
  ctrl.addSearcher(webSearch);

  var fullWebSearch = new google.search.WebSearch();
  fullWebSearch.setUserDefinedLabel("Teljes weben");
  ctrl.addSearcher(fullWebSearch);

Hasonló módon csinálhatunk külön füleket a magyar nyelvű találatoknak, amihez ún. restrictiont kell beállítani:

  var huWebSearch = new google.search.WebSearch();
  huWebSearch.setRestriction( google.search.Search.RESTRICT_EXTENDED_ARGS, { lr: 'lang_hu' } );
  huWebSearch.setUserDefinedLabel( "Magyar weben" );
  ctrl.addSearcher( huWebSearch );

Restrictionként tudjuk beállítani azt is, hogy ne csak moderált találatok jelenjenek meg, illetve az egyes searcher osztályok további lehetőségeket (pl. színes képek, nagy méretű képek stb.) biztosítanak. Nem biztos, hogy mindent be tudunk állítani az objektum modellen keresztül, lehetnek olyan esetek, amikor a kereső kifejezés kiegészítése a legegyszerűbb megoldás. Erre szolgál a setQueryAddition metódus, amivel például dokumentum típusa szerint kereshetünk:

  var pdfWebSearch = new google.search.WebSearch();
  pdfWebSearch.setUserDefinedLabel("PDF dokumentumok");
  pdfWebSearch.setQueryAddition("filetype:pdf");
  ctrl.addSearcher(pdfWebSearch, searcherOptions);

Természetesen előfordulhat, hogy nincs találat, az ekkor megjelenő üzenetet a SearcherOptions objektum setNoResultString metódusával állíthatjuk be:

  var searcherOptions = new google.search.SearcherOptions();  
  searcherOptions.setNoResultsString( "Gratulálunk, sikerült olyan kifejezést megadnia, amire még a Google sem talál semmit. :(" );
  ctrl.addSearcher(webSearch, searcherOptions);

Ez működik mindenféle searcher objektum esetén, de figyeljünk oda arra, hogy az eredményhalmaz eltérő layoutja és CSS-e miatt előfordulhat, hogy máshogy jelenik meg az üzenet.

Mindez csak a jéghegy csúcsa, de ennyiből talán már látszik, hogy viszonylag egyszerűen, de ugyanakkor rugalmasan konfigurálhatóan hozzá be tudjuk építeni a Google keresőjét a saját webhelyünkre. Ugye nálad is lehet keresni?

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

 

Technorati-címkék: ,,,

Build error TSD00259: dbschema does not exist

Az egyik projektünkben a Data Dude-ot használjuk az adatbázis szkriptek kezelésére és azt kell mondanom, hogy egészen bevált. Azonban x64-es gépen nem sikerült lefordítanunk az x86-on tökéletesen működő projektet.

Akinek van VS 2008 Team System változata, annak feltétlenül érdemes kipróbálni a Data Dude-ot, teljes nevén a Visual Studio Team System 2008 Database Editiont, mert nagyon praktikus funkciók vannak benne az adatbázis forrásának kezeléséhez. Aki pedig szeret build környezetet automatizálni, annak érdemes megnéznie, mit tud a Data Dude Power Tools. Ráadásul ezek a funkciók a VS 2010-től kezdve már részben a Professional változattól is elérhetőek lesznek, érdemes minél előbb hozzászokni.

Az egyik kedves szolgáltatása ennek a projekt típusnak, hogy ismeri az SQL Server beépített adatbázis objektumait, ahhoz képes IntelliSense-t adni, hivatkozásokat ellenőrizni stb. Ehhez fel kell venni az objektumokat leíró .dbschema fájlokat referenciaként a projektbe:

Database references

Ez tökéletesen működött is x86-os gépen, ám amikor ugyanezt a projektet x64-en akartam fordítani, az alábbi hibaüzenetet kaptam:

“W:TFSMySolutionMySolution.sln” (Build target) (1) ->
“W:TFSMySolutionDatabaseDatabase.dbproj” (default target) (3) ->
(DspBuild target) –>
C:Program Files (x86)MSBuildMicrosoftVisualStudiov9.0TeamDataMicrosoft.Data.Schema.SqlTasks.targets(58,5):
Build error TSD00259: File C:Program FilesMicrosoft Visual Studio 9.0VSTSDBExtensionsSqlServer2008DBSchemasmaster.dbschema does not exist.
C:Program Files (x86)MSBuildMicrosoftVisualStudiov9.0TeamDataMicrosoft.Data.Schema.SqlTasks.targets(58,5):
Build error TSD00259: File C:Program FilesMicrosoft Visual Studio 9.0VSTSDBExtensionsSqlServer2008DBSchemasmsdb.dbschema does not exist.

És milyen igaza van, x64-en tényleg nincsenek .dbschema fájlok a C:Program Files mappában, mert a C:Program Files (x86) mappában vannak. A megoldás a project fájl kézi átírása. A hibás rész ez:

  <ArtifactReference
    Include="C:\Program Files\Microsoft Visual Studio 9.0\VSTSDB\Extensions\SqlServer\2008\DBSchemas\master.dbschema">

Írjuk át erre:

  <ArtifactReference
    Include="$(VSTSDBDirectory)\Extensions\SqlServer\2008\DBSchemas\master.dbschema">

Az msdb.dbschema fájllal ugyanezt kell eljátszanunk, utána fordulni fog a projekt mindkét architektúrán. Érdekes, hogy az Microsoft.SqlTypes.dbschema fájl útvonalát sikerült korrektül rögzítenie, csak a master és az msdb problémás.

Technorati-címkék: ,,,

Toshiba Tecra S10 és az ujjlenyomat olvasás Win7 x64 alatt

Nemrég telepítettem egy Toshiba Tecra S10 laptopra 64-bites Windows 7-et. Gyakorlatilag minden eszközzel sikerült pillanatok alatt megbirkóznom, de az ujjlenyomat olvasónak olyan sajátosságai vannak, hogy azt már fel kell jegyeznem magamnak és az utókornak.

A gépben egy AuthenTec AES1610 típusú olvasó van, ami egy jó terméknek tűnik (kolléga HP gépén az ottani szoftverrel panasz nélkül megy). A gyárilag előre telepített Vistán az AuthenTec TrueSuite szoftverével lehetett kezelni az ujjlenyomatokat, de mivel telepítő nem volt hozzá, így kénytelen voltam a Toshiba oldaláról letölteni a “Fingerprint Software”-t, szerencsére van belőle 64-bites. Már ott elkezdtem gyanakodni, amikor ugyanezen a letöltő oldalon találtam egy “Fingerprint Software Uninstaller”-t is.

A letöltés és a telepítés simán ment, de a konfigurálásnál folyton elakadtam. Gyakorlatilag az összes settings jellegű opció disabled volt és csak az Enroll (ujjlenyomat rögzítése) volt elérhető. Ha végigküzdöttem a varázslót, akkor az alábbi kimenetek egyikét értem el:

  • 3x bevittem a lenyomatot, de a 3 ellenőrző olvasásból csak az első kettő sikerült, a 3., 4., 5., 6. stb. soha.
  • A varázsló végén hibaüzenet: Operation Failed. Duplicate templates already exist.
  • A varázsló végén hibaüzenet: Input password is incorrect. Please retype current password.
  • Az ujjlenyomatokat sikerült rögzíteni, de bejelentkezni soha nem sikerült.

Felszántottam a webet, nem csak én küzdök hasonlóval. Ennek a szoftvernek vagy nagyon egyedi igényei vannak, vagy nagyon el van rontva.

Tapasztalatok:

  • Az AuthenTec jelenleg külön nem teszi elérhetővé a szoftvert, csak a PC gyártókon keresztül érhető el. A jövőben ez talán változni fog. Már Toshiba FingerPrint Utility (TFPU) néven fut és teljesen a Toshiba kezében van, de fórumokban sikerült ráakadni az alábbi linkre, ahonnan még a Windows 7 béta idején az AuthenTec által készített driver és szoftver tölthető le (nem próbáltam ki, de hátha segít valakin): http://win7beta.authentec.com/
  • Ellentmondásos információkat találtam arról, hogy pontosan hol tárolódnak az ujjlenyomatok, “Secure sensor-flash storage”-ban, vagy a diszken.
    • Az biztos, hogy nem operációs rendszer függő helyen, tehát dual boot esetén azt el kell felejteni, hogy több operációs rendszerből használjuk az olvasót.
    • Összesen maximum 20 lenyomat tárolható, ami lehet 1 felhasználó összes végtagjának a lenyomata vagy 20 felhasználótól 1-1 minta.
  • Windows bejelentkezés, mappa titkosítás, weboldalakra bejelentkezés működik tökéletesen Windows 7 x64 alatt, akár munkacsoportban, akár tartományban. Időnként előfordul, hogy boot után az első loginnál nem eszi meg az ujjlenyomatot, de később unlockolásra már jól használható.
  • A weboldalakra bejelentkezés csak 32-bites IE alatt megy (egy ronda sárga csík jelenik meg a weboldalak tetején), 64-bites IE és FF alatt nem. Nem minden weboldallal boldogul.
  • Fontos: Arra figyelni kell, hogy két felhasználónak ne legyen azonos bejelentkezési neve, még akkor sem, ha csak az egyikhez vettünk fel ujjlenyomatot. pl. ne legyen HELYIGÉPuser1 és TARTOMÁNYuser1 még akkor sem, ha TARTOMÁNYuser1 soha nem fogja használni ezt a gépet. A fenti kriptikus hibaüzenetek és jelenségeket idézheti elő.
  • A Delete All Fingerprints opció csodákra képes, nem csak törli a korábban rögzített lenyomatokat, hanem látszólag teljesen resetel mindent, ha gond van, érdemes kipróbálni.
  • A beállítások egy része csak Run as administrator módban érhető el. A beállító ablak alján található Run as administrator opció hasznos, de úgy vettem észre, hogy nem megbízható: néha akkor is megjelenik, amikor adminként futtatjuk és néha akkor sem, ha Gipsz Jakabként.

Végül lett egy használható rendszerem, de ezzel a hardverrel többet küzdöttem, mint az oprendszerrel és az összes többi hardverrel együttesen.

Technorati-címkék: ,,

Telepítő elhal a Completing installation fázisban

Épp egy Sun Fire X4275 szerverre telepítettünk Windows Server 2008 R2-t, amikor belefutottunk ebbe a hibába: a telepítő látszólag vígan működik, de a Completing installation… fázisban beragad. A progress bar és az egér megy, de a telepítés csak nem ér véget.

A hiba ismert, a megoldás az, hogy a Tools & Drivers DVD-ről kell kimásolni egy friss Ethernet Controller drivert és azt USB-n keresztül megetetni a telepítővel. Ezeknél a szervereknél (X4170, X4270, X4275) más operációs rendszerek telepítése esetén is érdemes elolvasni a Product Notes doksit, mert nem ez az egyetlen issue, ami elfordulhat. A Sun Installation Assistant sem segített, mert csak a Windows Server 2008-at ismeri, az R2 telepítő DVD-t nem volt hajlandó megenni.

Mottó: “Olvasott embernek párja nincs.”

ETags kontra webfarm

Ki látott már olyat, hogy miután új webszerver kerül egy farmba megnő a hálózati forgalom, sőt meghal a böngésző cache? Pedig IIS 7 előtt ez történik.

A böngésző cache elsősorban úgy működik, hogy az első lekérdezéskor a szerver visszaküldi az adott erőforrás (kép, oldal stb.) utolsó módosításának dátumát a Last-Modified fejléc mezőben, amit a böngésző az ismételt lekérdezéskor egy If-Modified-Since fejléc mezőben visszaküld a szervernek. A kiszolgáló csak akkor küldi le a teljes fájlt a kliensnek, ha a fájl frissebb, egyébként HTTP 304 Not Modified választ küld body nélkül.

Csakhogy utazik egy másik pár fejléc mező is, az ún. entity tag, azaz ETag. Az IIS valami ilyesmit küld vissza:

ETag: "0ba4e9b5277c71:5897"

A következő kérésnél pedig ezt az értéket így küldi vissza a kliens:

If-None-Match: "0ba4e9b5277c71:5897"

A válasz a dátumos megoldáshoz hasonlóan egyezés esetén 304, eltérés esetén 200 + az új tartalom. Az ETag mező tartalmára a HTTP 2616 Section 3.11 szerint gyakorlatilag csak annyi megkötés van, hogy egy idézőjelek közé zárt egyedi értéket tartalmazzon. IIS esetén ez FileTimeStamp:ChangeNumber értékekből áll, Apache esetén más formátumú a tartalom: inode-size-timestamp, például:

ETag: "ef15-424-eda08740"

Mindkét esetben az a probléma, hogy a ChangeNumber és az inode részeket a fájlrendszer tartja nyilván és az értékük gépről gépre jó eséllyel eltérő. Azaz ha csak egyetlen webkiszolgálónk van, akkor semmi probléma, amikor azonban egy NLBS farmot építünk és beteszünk egy második kiszolgálót, azon szinte biztos, hogy eltérő lesz a ChangeNumber és az inode érték. Következésképp míg egy kiszolgáló esetén a böngésző lelkesen a saját gyorsítótárából töltötte a tartalmat, a második szerver üzembe állítása után – ha a két kérés más szerverre esik be, akkor  – kénytelen letölteni a fájlt, hiába azonos mindkét szerveren. A végeredmény nagyobb hálózati forgalom és lassabb renderelés még akkor is, ha van If-Modified-Since fejléc, ugyanis az If-None-Match elsőbbséget élvez.

A megoldás nyilván az, hogy meg kell szabadulni a gépfüggő részektől:

  • IIS 5 (ugye már senki nem használ ilyet?!) esetén az mdutil.exe-vel lehet szinkronizálni az ETag értékeket, ld. KB 922733.
  • IIS 6 esetén be lehet állítani egy fix ChangeNumber értéket, ld. KB 922703. Itt előfordult néhány bug, érdemes megnézni a 823544 és a 900245 KB cikkeket is.
  • Apache esetén a FileETag direktíván keresztül lehet beállítani, hogy az ETag fejléc milyen fájl tulajdonságok alapján képződjön, ld. Apache Core Features.

A jó hír az, hogy IIS 7 esetén ezzel egyáltalán nem kell foglalkozni, ugyanis a ChangeNumber elveszítette jelentőségét, az értéke mindig fixen 0. Vegyes farm esetén a fenti módszerekkel ezt a 0 értéket kell IIS 6-on is beállítani. HTTP 1.1 esetén az elvárt viselkedés az, hogy a szerver küld ETag és Last-Modified fejléceket is, tehát teljesen nem célszerű megszabadulni tőle.

Összefoglalva tehát egy gép esetén nincs gond, több gépes farm esetén IIS 7 előtt figyeljünk oda erre a fejléc mezőre.

Technorati-címkék: ,,