ugrás a tartalomhoz

Rövid webcímek készítése és kezelése

Hojtsy Gábor · 2004. Júl. 27. (K), 21.00
Rövid webcímek készítése és kezelése
Manapság egyre ritkábbak az olyan oldalak, melyeket nem dinamikusan állítanának elő készítőik. Sokak számára jelentősen kényelmesebb valamilyen feladat-specifikus szerkesztővel elkészíteni az oldal tartalmait - mely lehetővé teszi a kategorizálást, meta információk megadását -, mint egy általános weboldal-szerkesztő programot elővenni a cél érdekében. Ez azonban ahhoz a sajnálatos következményhez vezetett, hogy a webcímek kórosan elburjánzottak, nagyon hosszúak és "csúnyák" lettek. Lássuk miért nem jó ez nekünk, és mit tehetünk ellene! Főleg Apache szerveren működő megoldásokat fogunk vizsgálni.

A szépség és a szörnyeteg

Szerencsére még megmaradt néhány archív link egyik elődünkről, a korábbi PHPInfo oldalról, amely PostNuke rendszerrel publikálta olvasói számára a tartalmakat. Íme egy hír linkje a korábbi oldalon, összehasonlítva ugyanannak a hírnek a mostani webcímével:

http://phpinfo.wish.hu/modules.php?op=modload&name=News&file=article&sid=595&mode=thread&order=0&thold=0
http://weblabor.hu/hirek/20030717/hircikkbekuldo

Lássuk mit mond az első webím: tölts be egy modult, amelynek a neve 'News', abban vedd elő azt az írást, melynek sorszáma 595, és a hozzászólásokat szálakkal jelenítsd meg, a régebbieket felül kiírva nullás megjelenítési küszöbbel. Két részre bonthatjuk az adott webcímet: a hír megjelenítésére vonatkozó részre és a hozzászólások preferenciáit tartalmazó részre. Ezutóbbi felhasználótól függő érték, illetve nem belépett tag esetén a webhely alapértelmezése. Tehát nincs semmiféle értelme a webcímben tartani, hiszen programozottan mindig előkereshető.

Az első rész a modul betöltésére vonatkozik, és vizsgálatunk szempontjából sokkal érdekesebb kérdéseket vet fel. Elsősorban a modul funkciói vizsgálatával lehet megállapítani, hogy a file=article részre szükség van-e. A News modul két állománnyal operál: az index egy hír listát jelenít meg, az article pedig egy konkrét hírt, tehát ez elfogadható paraméter. A modules.php állomány egyetlen használható op paramétere a modload, tehát bármi mással próbálnánk meghívni, nem adna értelmes választ. Röviden tehát a name, a file és a sid paraméterek létjogosultsága indokolható meg egyáltalán.

Összehasonlításképpen elmondhatjuk, hogy a mostani webcím sokkal kifejezőbb: magyar nyelvű; jelzi, hogy hírről van szó; benne van a dátum, és még a tartalomra utaló kis részlet is. Sokkal rövidebb és letisztultabb, ráadául nem utal benne semmi arra, hogy dinamikus oldalról lenne szó. A hírek esetében minden egyes tartalomhoz saját rövid címet rendelünk, ám ez nem feltétlenül szükséges. A dinamikus oldalak rövid és barátságos címeinek előállításának vannak automatikus módjai is. Ám mielőtt megnéznénk, milyen eszközeink vannak erre, lássuk miért is érdemes egyáltalán belefogni.

Nem csak kereső optimalizálás

A rövid webcímek használata számos pozitív hatást gyakorolhat webes jelenlétünkre. Nézzük sorban, hogy milyen előnyökkel járhat.
  • Kereső indexelés: Ami ezt illeti, többnyire sajnos csak mendemondákból tudunk ítélni. A Google webmestereknek szóló dokumentációja mindenesetre tartalmazza, hogy a dinamikus oldalak indexelését visszafogottan végzik, nehogy összeomlasszák a mögöttük futó programokat a kérésáradattal. A közhiedelem szerint a webcímekben megjelenő minden újabb dinamikusságra utaló karakter (?, &) az indexelés esélyének csökkenését jelenti, azaz például minél több paramétert adunk át a PHP szkriptünknek GET értékként, annál inkább dinamikusnak tűnik a kereső indexelője számára oldalunk. Ez meglehetősen logikus feltevés.

  • Megjegyezhető címek: A rövid címek könnyen megjegyezhetőek, és sokkal több helyre kihelyezhetőek. Ha a fent leírtak szerinti hírek index oldal címet képezzük a PostNuke módján, az sokkal barátságtalanabb lesz, mint ha egyszerűen azt mondanánk, hogy webhelyünk hirek mappájában vannak a hírek. Egy ilyen rövid webcím könnyen elfér névjegykártyán, hirdetésekben, akár rádióban bemondva is. Nem utolsó sorban szívesebben továbbítják értünk lelkesedő látogatóink emailben, hiszen nem kell tartani attól, hogy a webcím kettétörik a sortörésben. Egyes vélemények szerint ugyanez a pszhicológiai ok húzódik meg amögött is, hogy szívesebben linkelnek a rövid címekre. Valószínűleg ebben az is benne van, hogy általában profibbnak gondolják azt, aki ezt a technikát alkalmazza. A több ránk mutató link pedig rendkívül hasznos kereső optimalizálási szempontból, hiszen így találati oldalakon előrébb szerepelhetünk.

  • Méret optimalizálás: Tartalommal zsúfolt oldalakon (vagy legalábbis sok linket biztosító honlapokon) a hosszú webcímek kiírása jelentősen megnöveli az oldal méretét, mely a kiszolgálására és megjelenítésére fordított időt is növeli. Ha rövidebb webcímeket használunk, oldalunkon belüli kapcsolataink is kisebb HTML lapot eredményeznek. Ezt a törekvést kicsit visszavetheti, ha nagyon hosszú webhelyünk alapcíme (egy szolgáltatónál valamely eldugott alkönyvtárban van például). Ez sem okozhat problémát, hiszen a <base> HTML fejléc elemmel saját alapcímet határozhatunk meg a linkek számára. A méret optimalizálás egyik zászlóshajója a Yahoo! honlapja, ahol a következő formájú linkeket találunk:
    <a href=r/sh>Shopping</a>
    Itt a rengeteg link kiírása mellett csak ilyen rövid HTML kóddal tudták megoldani, hogy ne legyen túl nagy a HTML kimenet (sajnos az idézőjeleket is lespórolva). A base elem használatára is kiváló példát mutatnak, ebben adják át a munkamenet azonosítót. A méret csökkenés különben a kereső optimalizálásban is segít, a sallangokat kisebb mértékben, a tartalmat nagyobb súlyban hordozó oldalakat a keresők jobban szeretik (megint csak állítólagosan).

  • Könnyebb programozás: Ha rövid webcímeket szeretnénk használni, akkor jól át kell gondolnunk, hogy mit hova teszünk, annak érdekében, hogy a címek tartósan használhatóak legyenek. Ez rákényszerít minket arra, hogy átgondoljuk tartalmunkat, és egységes kialakítást hozzunk létre. Ezt követően azonban a rövid címekkel könnyebb lesz a dolgunk, hiszen kezelésük programunkban is egyszerű. A Weblabornál például a webcímek alapján döntjük el, hogy melyik fület kell a felső navigációban megjeleníteni. Ha egy webcím elején hirek szerepel, akkor a hírekhez tartozó fület nyitjuk le.

  • És még több előny a keresőknél: Ha még nem lett volna elég kereső optimalizálásból, meg kell említeni, hogy például a Google a webcímekben lévő kulcsszavakat is indexeli. Tehát ha olyan címet alakítunk ki, mint http://pelda.hu/kutya/eledel.html akkor ez az oldal már a címe miatt is jó eséllyel bukkan fel a kutya eledel keresésre. A tapasztalatok szerint a kötőjellel elválasztott szavak külön szónak számítanak az indexelésben.

Kés, villa, olló

Most, hogy már tudjuk, hogy van élet a borzalmasan kialakított webcímeken túl, ráadásul ez napossabbá teszi fejlesztéssel töltött óráinkat, és még a közben fogyasztott kávét is megízesíti, lássuk, miként léphetünk be a rövid webcímekkel dolgozók táborába.

1: PATH_INFO

Ez a módszer eléggé könnyen megvalósítható olyan szervereken is, ahol különben nem tudjuk befolyásolni a beállításokat. A webszerverek azon tulajdonságán múlik, hogy amennyiben nem találnak meg egy webcímhez tartozó dokumentumot, akkor a perjelek mentén visszafelé lépdelve megnézik, hogy az előtagok valamelyike nem található-e meg a kiszolgálón. Lássunk egy ilyen címet:

http://pelda.hu/konyvek.php/12

Ezen webcím lekérésekor a szerver felismeri, hogy nem található a teljes címhez illeszthető állomány, ezért visszalép a konyvek.php-re, amit meg is talál. A PHP állományban elérhető a $_SERVER['PATH_INFO'] értékben a PHP szkript neve után található információ. Ezzel aztán bármit kezdhetünk, ha konkrétan könyv sorszámot vártunk, akkor valami ehhez hasonlót javasolnék:

<?php
// Ha kaptunk sorszamot, akkor azt vesszuk le egesz szamma alakitva, kulonben 0 az alapertelmezes
$sorszam = (isset($_SERVER['PATH_INFO']) ? intval(substr($_SERVER['PATH_INFO'], 1)) : 0);

if ($sorszam) {
  // Valamilyen kod, ami eloveszi az adott konyvet
}
else {
  // Valamilyen kod, ami hibat ad, vagy
  // egy konyv index oldalt ir ki
}
Természetesen nem csak egy információ morzsát adhatunk így át, az "alkönyvtárak" száma tetszőleges lehet. Ennek ellenére ennek a módszernek két kézenfekvő hátránya is van. Az egyik, hogy minden lehetséges tartalom típushoz el kell helyeznünk egy PHP állományt, a másik pedig az, hogy továbbra is látszik, hogy PHP-vel operálunk, csak a webcímet sikerült rövidíteni. Először is lássunk egy megoldást a második problémára.

2: PATH_INFO + ForceType

Ha Apache szervert használunk, nem kell feltétlenül PHP kiterjesztést adnunk szkriptünknek ahhoz, hogy azt a PHP feldolgozza. Valójában bármilyen állományt PHP típusúvá kényszeríthetünk. A következőt kell elhelyeznünk webhelyünk gyökérkönyvtárában egy .htaccess állományban (vagy bármilyen más módon az Apache tudtára kell adnunk):

<Files "konyvek">
 ForceType application/x-httpd-php  
</Files>
Ahhoz, hogy ezt használhassuk, a FileInfo engedélyt tartalmaznia kell az adott könyvtárra érvényes AllowOverride beállításnak. Ha tehát a fenti kód hatással van a könyvtárban lévő állományokra, akkor a konyvek.php-t átnevezhetjük konyvek-re, és a továbbiakban használhatjuk az első metódust a PATH_INFO kezelésére. Webcímeink továbbra is közvetlenül tartalmazni fogják a PHP állomány nevét, ez azonban csak a webszerver számára lesz ismert tény. Ezzel a módszerrel létrehozhatunk további hirek, cegunkrol és hasonló nevű állományokat, melyek ilyen nevű "könyvtárakként" jelennek meg majd a látogatók számára.

Innentől kezd érdekes lenni az, hogy a keresőrobotok visszafogják a dinamikus oldalak indexelését, hiszen statikusnak látszó oldalunkkal kapcsolatban ilyen fenntartásaik már nem lesznek. Ezért hatékony gyorsítótárazást és/vagy más módszereket kell alkalmazni annak érdekében, hogy ne omoljon össze szerverünk egy-egy Google vagy MSNBot támadás során.

Mint említettem ez a módszer ugyan megoldotta a dinamikusság látszatának elfedését, de ugyanakkor nem növelte eléggé a belső rugalmasságot a webcímek kezelhetőségét illetően. Még két módszer van a tarsolyunkban, melyek az első kettőnél sokkal rugalmasabbak, és végre elfelejthetjük azt a megkötést, hogy minden "alkönyvtárnak" egy-egy PHP szkriptet kell megfeleltetni.

3: ErrorDocument

Kulcsszavunk ezúttal az ErrorDocument, azaz a hibák kezelésére szolgáló dokumentum beállításának lehetősége. Amennyiben az Apache egy nem létező webcímet kap, és a fent említett visszalépéssel sem tud értelmes előtagot találni benne, akkor elindítja hibakezelő mechanizmusát. Ennek a folyamatnak a helyére könnyen delegálni tudjuk saját szkriptünket, mely magára vállalja a nem található oldalak kezelését. Ismét egy .htaccess állományt kell létrehozni, most a következő tartalommal:

ErrorDocument 404 /cimkezelo.php
Ez a beállítás azt eredményezi, hogy minden "nem található oldal" (azaz 404-es) hiba esetén a webhelyünk gyökerében lévő cimkezelo.php fog lefutni. Ahhoz, hogy ennek a .htaccess állománynak hatása legyen, ismét csak az előbbi módszernél említett jogosultságnak kell érvényesnek lennie mappánkra.

Ezzel az eszközzel felvértezve a szerverünkön például a /termek/54 cím meghívására a webszerver meg fogja állapítani, hogy ilyen állomány nem létezik, ezért a cimkezelo.php szkriptnek adja át a vezérlést egy átirányított HTTP lekérdezést indítva. A következőképpen tudjuk lekezelni a kérést:

<?php
// Kapjuk el azt az cimet, amit kertek es az alapjan dontsuk el, mit toltunk be
$URI = (isset($_SERVER['REQUEST_URI']) ? substr($_SERVER['REQUEST_URI'], 1) : '');
$URIparts = explode("/", $URI);

switch ($URIparts[0]) {
  case 'hirek':
    status200();
    // Hirek modul betoltese es lekezeles
    break;
  case 'termek':
    status200();
    // Termekeket kezelo modul betoltese es lekezeles
    break;
  default:
    // Nem azonosithato cim tipust kertek
    break;
}

function status200()
{
  // Mukodjon PHP 4.3.0 elotti verzioval is
  @header("HTTP/1.1 200 OK");
  @header("Status: 200 OK", TRUE, 200);
}
A kapott webcímet először megszabadítjuk a kezdő perjeltől, majd feldaraboljuk, hogy az első komponenst megkapva ki tudjuk választani a megfelelő modult, mely lekezeli a kérést. Természetesen lehet egy előre megadott címkezelő függvény hozzárendelési táblát is használni, vagy bármilyen bonyolultabb megoldást választani. Nagyon fontos azonban arra figyelni, hogy most egy 404-es hibát kezelünk, és ha sikerül megtalálnunk a jó oldalt, akkor a válasszal megadott állapotot is meg kell változtatni, tehát ha azonosítható és betölthető tartalmat kértek, akkor a HTTP állapot fejlécet 200 OK státuszra kell állítani. Ha nem megfelelő címet kértek, akkor maradhat a 404-es állapot.

Kipróbálhatjuk a $_SERVER tömb tartalmának kiírását. Látni fogjuk, hogy számos REDIRECT_ kezdetű érték jelenik meg, melyek lehetőséget adnak arra, hogy megtudjuk például, hogy milyen hibakód kezelése érdekében hívta meg a szkriptet a szerver, illetve a REDIRECT_URL-ben is megkaphatjuk az átirányítás előtti címet.

Ezen módszer előnye, hogy - az előbbiekkel ellentétben - tetszőleges címformák kezelésére jó, nem igényel egy-egy PHP állományt minden "könyvtár" bevezetéséhez. Ezen kívül eléggé egyszerűen beállítható, és az Apache jellemző telepítésén nyugodtan használható (amennyiben nem tiltották le számunkra). Hátrányaként felhozható, hogy a 404-es hibák mindig egy újabb bejegyzést jelentenek majd az Apache hibanaplójában alapbeállítások mellett, ezért felesleges hibaáradattal tölthetjük el a hibanaplót.

4: URL Rewrite

Az Apache URL Rewrite (vagy IIS szerverekhez az ISAPI Rewrite) lehetővé teszi, hogy az Apache kérések kiszolgálásába ágyazott mintaillesztő kifejezéseket írjunk, melyek a folyamat elején megváltoztathatják a szerver által kezelt webcímet. Ezzel elérhetjük, hogy az előző módszer átirányított lekérdezése helyett rögtön az adott lekérdezésben kezeljük le az igényelt címet, csupán azt kell tudnunk, hogy miként tudjuk a webcím átírásokat megvalósítani.

Első megközelítésben megoldásunk nem fog többet nyújtani, mint a fenti ErrorDocument alapú változat, csak éppen másképp oldjuk meg ugyanazt a feladatot. A kezünkben lévő rugalmasság csak később tárul fel. Ismét egy .htaccess állományt fogunk létrehozni a következő tartalommal. A példa a Drupal forráskódjából származik.

<IfModule mod_rewrite.c>
  RewriteEngine on

  # Ebben az alkonyvtarban vagyunk, ezt
  # figyelembe kell venni az atirasoknal
  #RewriteBase /cegunkwebhelye

  # Minden nemletezo oldal webcimet iranyitsuk at az index.php-re
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteRule ^(.*)$ index.php?q=$1 [QSA]
</IfModule>
Először is nem biztos, hogy be van kapcsolva a szerveren a Rewrite modul támogatása, ezért egy ilyen feltételes részbe burkoljuk az utasításainkat. Ha nem így tennénk, akkor kikapcsolt Rewrite modul esetén 500-as hibát kapnánk a könyvtár minden állományára és az alkönyvtárakra is, ami nem túl kellemes élmény.

Minden Rewrite modulhoz kapcsolódó direktíva a Rewrite kulcsszóval kezdődik, és általában valamilyen mintaillesztő kifejezés vagy más feltétel segítségével teszi lehetővé a webcím átalakítás megvalósítását.
  • A RewriteBase azt adja meg, hogy milyen alapkönyvtárat kell figyelembe venni. Ezt akkor használjuk, ha a webhelyünk valamilyen alkönyvtárban van, mert akkor a további feltételekbe ezt az alkönyvtárat már nem kell belekódolni, és egyszerűbb lesz a könyvtárváltás, ha később szükségessé válik.

  • A RewriteCond olyan feltételeket ad meg, melyek teljesülése a soron következő RewriteRule végrehajtásához feltétlenül szükséges. Itt az adott lekéréshez kapcsolódó változókat is használhatjuk. A példában használt első feltétel ellenőrzi, hogy a kért webcím nem egy állomány, a második feltétel pedig akkor teljesül, ha nem létező könyvtár nevét kérték. Tehát ha nem létező állományt, és nem is létező könyvtárt kértek, akkor hajtódik végre az átírási szabály.

  • A RewriteRule szabja meg azt, hogy az előzetesen megadott feltételeknek megfelelő webcímet végülis miként kell átírni. Itt mintaillesztő kifejezés segítségével azt adjuk meg, hogy a teljes webcímet az index.php q nevű paraméterébe tegyük át. A szögletes zárójelben a webcím átírás egyéb beállításai találhatóak. A QSA azt kéri, hogy egy esetleges GET lekérdezési paraméter listát a megadott lista végére fűzze fel az Apache. Két példa a webcím átírás eredményeire:

    /hirek/14       =>  /index.php?q=hirek/14
    /hirek?oldal=2  =>  /index.php?q=hirek&oldal=2

Megjegyzendő, hogy nem csak egy átírást fogalmazhatunk meg. Valójában több átírási blokkot alkalmazhatunk, melyek a saját blokkjukban megadott feltételek szerint hajtódnak végre. Ráadásul több Rewrite direktíva is rendelkezésre áll, melyeket most nem ismertetnék. További információért érdemes megnézni a modul dokumentációját.

A Rewrite modul által kezelt bejövő kérések különleges kezelésével nem is kell törődnünk, hiszen az általunk megadott PHP állományban fognak kikötni. Természetesen külön irányításokat készíthetünk a hirek kezdetű webcímekre, hogy az a hírek modulnak megfelelő hirek.php-re irányítson, és a dolgot tovább bonyolíthatjuk, de végső soron a PHP szkriptjeinkhez egy hagyományos HTTP lekérdezés fog eljutni, és a GET/POST változókat minden gond nélkül tudjuk kezelni. Emiatt ez a megoldás eléggé jól használható kész alkalmazások "előtétjeként" is. A Rewrite megoldás másik előnye, hogy kevesebb erőforrást foglal, mert a kérést magát módosítja feldolgozás közben, és nem egy átirányított lekérdezést indít. Mindezekkel az előnyökkel persze csak akkor élhetünk, ha jó mintaillesztési ismereteink vannak és a Rewrite modul az adott kiszolgálón rendelkezésre áll.

Dobj vissza kenyérrel

Megismerve a rövid webcímek kezelésének technikáit, felmerül a kérdés, hogy mégis miként tudjuk ezekre irányítani a felhasználókat. Alkalmazásunkat fel kell készíteni arra, hogy rövid webcímeket írjon ki a választott technológiának megfelelően. Az, hogy belsőleg 404-es hibára képezzük le a címet vagy Rewrite modult használunk, csak a kérés kiszolgálása szempontjából érdekes, a felhasználó nem fogja észrevenni a különbséget, ha minden esetben a szép rövid webcímeket írjuk ki. A teljes alkalmazásnak késznek kell lennie arra, hogy ha egy webcímet kiírunk, akkor az a megfelelő formában jelenjen meg.

A rövid webcímek technikáinak megismerése kapcsán sokakban felmerülhet, hogy saját webhelyüket is ilyen kialakításúra szeretnék változtatni. Egy ilyen vágy megszületését némi előkészítésnek kell követnie. Először is meg kell állapítani, hogy milyen ráhatás lehetséges a webhelyet működtető motorra. Ha saját készítésű szkriptekről van szó, akkor a változtatást "könnyű" keresztülvinni, hiszen a webcímek kezelésének módját kell csak átalakítani.

Ha azonban egy kész alkalmazást használunk (mint például a cikk elején emlegetett PostNuke), akkor a váltás sokkal nagyobb dió. A PostNuke például minden zsigerében hosszú és paramétergazdag webcímek generálására van felkészítve, és erről nagyon nehéz lebeszélni. A Mountain Research and Development publikálta a PostNuke rövid webcímekkel kapcsolatos ismertetőjét. Itt fogadási oldalon az említett Rewrite szabályok széles garmadáját használják fel. Lássunk két példát:

# News-main.html es hasonlok iranyitasa a modules.php-re
RewriteRule ^([^\+]+)\+main.html$ modules.php?op=modload&name=$1&file=index [L]

# Teljes cikk olvasasa alapertelmezett parameterekkel
RewriteRule ^displayarticle([0-9]+).html$ modules.php?op=modload&name=News&file=article&sid=$1&mode=thread&order=0&thold=0 [L]
A webcím átírás itt már jóval túlmutat a 404-es hibakezelés megoldásain, hiszen a lekért címek bizonyos tulajdonságai alapján más-más paraméterezést állít elő. Egyáltalán nem lehetetlen persze a 404-es hibakezelést alkalmazni, és PHP-n belül elvégezni a webcímek áltakítását, de mivel végül mindenképpen a mintaillesztő kifejezésekhez kell nyúlni, ezért csak az URL Rewrite szintaktikájának megismerésétől tudjuk magunkat megóvni.

Ami a kiírást illeti, a megfelelő webcímek kimenetre kerülését egy kimeneti buffereléses megoldással valósították meg, azaz a PostNuke által generált teljes oldalt a memóriában tartják, majd kiküldés előtt egy PHP-ben megvalósított hosszú webcím -> rövid webcím konverziót követnek el. Hasonló megközelítés bármilyen rendszer esetén alkalmazható, és bár a webcím problémát megoldja, hatékonynak nem nevezhető.

Az üveghegyen is túl

Az is előfordulhat, hogy nem meglévő rendszerünk köré akarunk gyógyító kódokat építeni, hanem teljes váltást szeretnénk megvalósítani jelenlegi rendszerünkről valami új (legalábbis rövid webcímeket támogató) megoldásra. Ezesetben különösen érdemes figyelnünk arra, hogy korábbi webcímeink továbbra is elvezessék a látogatókat a célhoz, és hogy HTTP átirányítással tegyék mindezt. Nem elhanyagolható szempont, hogy váltásunk után a keresőrobotok első látogatása során oldalaink törlődni fognak az indexekből, ha 404-es válaszokat adunk lekéréseikre. Ezért régebbi címeinket úgy kell kezelnünk, hogy azok a tartalmak új oldalaira irányítsanak át. Ha a cikk elején említett korábbi PostNuke címet kipróbálod, látni fogod, hogy az egyenesen az új címre irányít. Így a ránk linkelő oldalak és a keresőrobotok is megtudják, hogy mi lett a tartalom új címe és ezt teszik a korábbi webcím helyére.

Annak érdekében, hogy a váltás után a webcímek átírása a keresők adatbázisában automatikus legyen, egy dologra mindenképpen oda kell figyelni. A régi webcímek esetében nem szabad önműködő belső átirányításokat végezni, hiszen akkor a régi webcímek továbbra is működnek, és a keresők folytatják a hosszú webcímes találatok szolgáltatását. Ehelyett HTTP átirányítást kell eszközölni, mégpedig a 301 Moved Permanently állapotkóddal, mely alapján a keresőrobot meg fogja érteni, hogy a korábbi tartalom átmozgatott megfelelőjének címét adjuk át, melyet az adott tartalom új címeként kell kezelni. Lássunk erre egy példát a 404-es kezelő módosításával:

<?php
// Kapjuk el azt az cimet, amit kertek es az alapjan dontsuk el, mit toltunk be
$URI = (isset($_SERVER['REQUEST_URI']) ? substr($_SERVER['REQUEST_URI'], 1) : '');
$URIparts = explode("/", $URI);

switch ($URIparts[0]) {
  case 'hirek':
    http_status(200);
    // Hirek modul betoltese es lekezeles
    break;
  case 'termek':
    http_status(200);
    // Termekeket kezelo modul betoltese es lekezeles
    break;
  default:
    // Korabbi hirek lekezelese
    if (preg_match("!^modules.php\\?op=modload&name=News&file=article&sid=(\\d+)!", $URI, $match)) {
      header("Location: /hirek/$match[1]");
      http_status(301);
      exit();
    }
    // Valamilyen mas nem jo cimet kertek, azt is le kell kezelni
    break;
}

function http_status($code = 200)
{
  // Allapotnevek
  $string = array(
    '200' => 'OK',
    '301' => 'Moved Permanently'
  );
  $status = $string[$code];
  
  // Mukodjon PHP 4.3.0 elotti verzioval is
  @header("HTTP/1.1 $code $status");
  @header("Status: $code $status", TRUE, $code);
}
Ez természetesen csak egy kis megvalósítási példa, mindig az adott körülmények között alkalmazott webcím sémákat kell figyelembe venni. Felmerülhet az, hogy a modules.php paraméter sorrendje túlságosan is kötött a kódban. Ez tapasztalatok szerint nem jelent problémát, hiszen a PostNuke szinte mindig ezt a paraméter sorrendet adja ki.

Összefoglalás

Reményeim szerint cikkemmel sikerült felébreszteni a vágyat arra, hogy egyre többen térjenek át a felhasználó-, kereső- és sávszélesség barát rövid webcímek használatára, akárcsak úgy, hogy egy meglévő rendszert foltoznak meg ilyen formában. Meglepődnék, ha nem merülnének fel további kérdések a téma kapcsán, hiszen sok ponton éreztem azt, hogy akár többet is lehetne mondani, vagy jobb példákat is lehetne adni. Kíváncsian várom a véleményeket!
 
Hojtsy Gábor arcképe
Hojtsy Gábor
A Weblabor szerkesztője, mérnök informatikus. Több nemzetközi webfejlesztéssel és tartalomkezeléssel foglalkozó konferencián adott már elő, a hazai Web és Drupal konferenciák egyik szervezője. Szabadidejében legszívesebben amatőr színjátszással és énekléssel foglalkozik. Meggyőződése, hogy a pirospöttyös az igazi.
1

valami => valami.php

T.G · 2004. Júl. 27. (K), 21.48
Apache-ban van lehetőség arra is, hogy a valami.php -ra valami -ként hivatkozzunk, tehát a szerver automatikusan hozzáadja a .php -t, így nem szükséges valami nevű fájl és a ForceType.
Ha értenék hozzá, akkor leírnám a modul nevét is, de... :)
38

MultiViews

ada · 2007. Jún. 26. (K), 22.00
Apache Options direktíva MultiViews beállítása képes erre. Bár ennek használata szerintem nem javasolt.
2

Zsír

prodg · 2004. Júl. 27. (K), 21.59
Pont ezen bitliszkedek itt. GOBA mester kitalálod a gondolataimat. Ez melyik APACHE modulban van? :)))
8

Melyik melyik?

Hojtsy Gábor · 2004. Júl. 28. (Sze), 18.55
Hozzászólásod közvetlenül a cikkhez érkezett (nem egy másik hozzászólásra). Mivel a cikkben több módszert ismertetek, az ez hivatkozás célpontját nem tudom feloldani. Így nem tudok válaszolni :) Vagy egy gondolatkitaláló modulra gondoltál?
3

Egy s más az apache tréfáiról

chx · 2004. Júl. 27. (K), 22.49
1. Ahhoz hogy RewriteRule-jaink működjenek, AllowOverride File jogunk kell hogy legyen.

2. Apache2 alatt életünk az AcceptPathInfo direktíva szinesíti, amiről ha nem tudunk, akkor kitépjünk a hajunkat, hogy miért nem megy a kedvenc PHP scriptünk, ami Apache1 alatt pöpecül ment...

3. A RewriteRule jobb oldalán néha kell / jel az egész mindenség elé. Néha megél anélkül is. Például a Drupal-ban eredetileg ugyebár nincsen, mint azt a fentiekben láttuk. Ám mint a Drupal.org-on is jeleztem, azért néha nem árt, aztán a yuit nevű user is jelezte ugyanezt. Tehát, ha valaki végtelen redirect ciklust lát a rewrite log-ban, akkor térjen át abszolút pathra a rewrite rule-ban. (1.3.28 és felette van rewrite szám korlátozás. De a Debian Woody-ban az Apache az ugye 26-os, amíg meg nem unjuk és le nem cseréljük a dotdeb.org-ról.)
4

Még egy lehetőség...

sajt · 2004. Júl. 28. (Sze), 10.11
Az is egy lehetőség, hogy statikus oldlakat generálunk... (Végülis ez hasonlít a cache-eléshez.)
Ezenkívűl lehet ilyet is csinalni, a ForceType helyett:

AddType application/x-httpd-php .php .html

Ekkor ugye a html állományokat is php-ként kezeli.

Egyébként azt hallottam, hogy nagy leterhelésnél nem jó mod_rewrite-ot használni.
5

Inkább

Bártházi András · 2004. Júl. 28. (Sze), 11.11
Hát én már láttam közelről elég nagy és terhelt site-okat, ahol erősen vannak rewrite_rule-ok. Amit esetleg nem érdemes használni, az a -f és hasonló file ellenőrzések, inkább könyvtár szerint kell szűrni.

-boogie-
6

-f valóban

Hojtsy Gábor · 2004. Júl. 28. (Sze), 18.51
A PHP.net mint nagyon terhelt webhely terhelés csökkentésében eléggé sarkalatos volt, hogy a file létezés vizsgálatok helyett (file_exists hivások voltak) SQLite adatbázis lekérdezés történjen a filenevek listájára (egy lekérdezés több file_exists helyett). Ez hatékonyabb lett állítólag. Én nem ástam bele magam, csak figyeltem :)
7

Paraméterezés

Hojtsy Gábor · 2004. Júl. 28. (Sze), 18.53
Nem a kiterjesztéstől való megszabaduláson van a hangsúly, hanem a GET paraméterektől való megszabaduláson - úgy, hogy közben nem térünk át POSTra, mert akkor végképp kizárjuk a keresőket.
9

301 vs. 302

T.G · 2004. Júl. 29. (Cs), 09.25
Mi a különbség a két fejléc között?
A szövegben 301, a kódban 302 szerepel. Miért?
10

301

Bártházi András · 2004. Júl. 29. (Cs), 09.41
A 301 a helyes, mindjárt javítom. A 301 egy olyan címet küld le, mely "örökre" megváltozott, míg a 302 egy olyat, ami átmenetileg. A 301-es cím minden további nélkül becache-elhető a böngésző által, nem kell még egyszer megkérdezni, elköltözött-e, míg a 302 esetén igen, kivéve, ha egy HTTP fejléc a cache-elést engedélyezi.

További infó: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

-boogie-
11

Kiegeszites!!

dtaylor · 2005. Jan. 16. (V), 18.12
Szia!

Leirom okulasul:
<IfModule mod_rewrite.c>
RewriteEngine on

# Ebben az alkonyvtarban vagyunk, ezt
# figyelembe kell venni az atirasoknal
#RewriteBase /cegunkwebhelye

# Minden nemletezo oldal webcimet iranyitsuk at az index.php-re
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?q=$1 [QSA]
</IfModule>


Mukodik jol, de 2-3 szor futtatja le az oldat. Hosszas dibág utan kiderult:
keresi a favicon.ico-t. Mivel az nincs ott, ezert szorgalmasan dobalja az index.php-nek! Oda kell teni egy favicon.ico-t, vagy
RewriteCond %{REQUEST_FILENAME} !favicon\.ico  [NC]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?node5param=$1 [QSA]

formaban kell irni a rewrite rule-t!



--
[ Dönci ]
12

favicon.ico, robots.txt

Hojtsy Gábor · 2005. Jan. 16. (V), 18.58
A favicon.ico és robots.txt állományokról különben is érdemes gondoskodni, gyakran előfordul, hogy mindenféle kliensek lekérdezik.
13

favicon/robots

dtaylor · 2005. Jan. 16. (V), 23.27
Szia!

Igaz. De ez itthon volt devel gépen. Hol vagyok meg attol, h. robots.txt-re szukseg legyen! :) Mindenesetre, ha nincs, oda kell irni a rule-ok koze...

Persze, jobb ezeket ekesziteni, egyertelmu.
--
[ Dönci ]
14

?PHPSESSID

mammuth · 2005. Jan. 21. (P), 17.04
hi, nagyon tuti a cikk, jelentős segítséget nyújtott, ezentúl minden sitet rövid url-el fogunk csinalni, köszi! a rewrite rule-os megoldást valasztottuk végül, az tünt a legtisztábbnak, működik is szépen, mint a kisangyal. egyetlen egy gond vetődött fel, a session-el mukodo sitek az elso oldalon valamennyi rövid url után odabiggyesztik a session ID-t.... igy nez ki minden link:
http://www.web.hu/rovid/link?PHPSESSID=e175c15e20 bla bla, még egy csomo szam)
ha innen tovabb lepunk akarmelyik linkre a jelenseg megszünik, de azt szeretnem, ha mar ekkor sem lenne. van-e valami ötlet, találkozott-e valaki hasonló problémával? előre is kösz.
15

csak süti használatával

Hojtsy Gábor · 2005. Jan. 21. (P), 17.12
Kiváló kérdés. Amikor munkamenetet indít a PHP, akkor megpróbálja a lehető legtöbb módon továbbítani az azonosítót. Aztán ha látja, hogy sütiben megjött, akkor nem rakja be többet a linkekbe, de ha nem jön meg sütivel, akkor továbbra is a linkekbe teszi. Namost ha biztosak vagytok benne, hogy látogatóitoknak van süti támogatása (ez ma szinte mindenhol alapkövetelmény), akkor kikapcsolhatjátok a linkben próbálkozást.

Kapcsold be a session.use_only_cookies beállítást, vagy nagyon régi PHP-khez az url_rewriter.tags értékét ürítsd ki.
16

trans_sid

mammuth · 2005. Jan. 21. (P), 21.06
hi, koszi a tanacsot, annyival kiegeszitenem, hogy alapban a session.use_only_cookies 1-re allitasa még nem oldotta meg egymaga a problemat, a session.use_trans_sid kikapcsolásával viszont tökéletes eredmény produkalodott! nem is tudom eddig minek volt bekapcsolva, az tok kellemetlen mikor siddel kuld egy urlt valaki es esetleg belepsz a neveben...
17

Lenne egy kérdésem, megprob

Anonymous · 2005. Feb. 9. (Sze), 09.15
Lenne egy kérdésem, megprobálom értelmesen leírni hogy mi a bajom:
A PATH_INFO + ForceType -os megoldással minden müxik, de ugye úgy van pl valami.hu/konyvek/12 itt ugye a könyvek(.php) ami feldolgozza a dolgokat, de tegyük fel azt akarom elérni hogy
valami.hu/12 , és itt azt szeretném hogy az index file, dolgozza fel hogy /12 (az a path infot-) de ugye nem szeretném hogy az legyen hogy valami.hu/index/12 mert ez ugye elég bután néz ki :)))
Szóval ha erre tudtok valami megoldást osszátok meg velem :)))
18

Csak rewrite vagy errordocument

Hojtsy Gábor · 2005. Feb. 9. (Sze), 10.52
Szerintem ehhez a forcetype már nem elég, a rewrite kell vagy errordocument.
19

ErrorDocument

Anonymous · 2005. Feb. 17. (Cs), 14.52
Sziasztok,
Egy kis segitseget szeretnek kerni.
Adott egy oldal, ahol a rewrite_modul nem engedelyezett, ezert az url-k roviditeset ErrorDocumentes megoldassal kezelnem. Azonban, ha
van egy form-om ahol a parameterek POST metodussal kerulnek atadasra es a form action-je egy nem letezo url, akkor a redirect utan, a $_HTTP_VAR_POST valtozoban az elkuldott parameterek nincsenek benne.
Ha kiiratom a $_SERVER parametereket a kovetkezot kapom
Key: REDIRECT_REQUEST_METHOD; Value: POST (Tehat a redirect elott, meg POST)
Key: REQUEST_METHOD; Value: GET (Viszont ez mar GET, a POST helyett).
Gondolom az a gond, hogy a REQUEST_METHOD nem POST ezert, a php letre sem hozza a valtozot.

Valami otlet, hogy lehetne kikuszobolni ezt a problemat?
20

Szivacs. Én is csináltam

Anonymous · 2005. Már. 9. (Sze), 23.32
Szivacs. Én is csináltam ilyet, de valamilyen doksiban (Apache 1.3 doksijában) rábukkantam, hogy mindenképpen GET lesz a POST-ból, tetszőleges redirect esetén. Tehát nem csak errordocument esetén: "a redirect will lose the POST information".
21

Lokálisra nem igaz

Hojtsy Gábor · 2005. Már. 10. (Cs), 00.38
Lokális átirányításra nem igaz, távolira viszont igen. Olvasd figyelmesebben, amit belinkelsz.
23

biztos?

Őry Máté · 2005. Jún. 3. (P), 08.54
Amikor én utoljára kipróbáltam az errordocot, nem találtam olyan böngészőt, amivel ne maradt volna üresen a $_POST supglob változóm postoláskor. Forcetype-pal+ pathinfóval már ment.
Maat
24

biztos

Hojtsy Gábor · 2005. Jún. 3. (P), 09.15
Nem tudom, megfigyelted-e, hogy redirectről beszélünk itt már, és nem errordocumentről.
25

nem, de..

Őry Máté · 2005. Jún. 4. (Szo), 16.52
De ettől szvsz fönnáll a probléma, hogy miért nem lehet(ett?) postot használni errordocos megodásnál. Nem próbáltam újra, ugrottam rewritera ill. ahol nem lehet forcetype egy "hu" file-ra.
Maat
26

Apache tervezők

Hojtsy Gábor · 2005. Jún. 4. (Szo), 17.40
Ezt talán az Apache tervezőitől kellene megkérdezni. Ez ugyanis így működik.
35

magyarul

Anonymous · 2006. Ápr. 12. (Sze), 17.01
This error occures only when not-founded-page consists any path.

Examples:
1) http://www.anyserver/path - POST parameters are lost during processing
"ErrorDocument 404 /index.html" directive.

2) http://www.anyserver/ - POST parameters are correctly processed during
processing "ErrorDocument 404 /index.html" directive.

hogy más ne szivjon ezzel...
22

Eltűnő perjelek

attlad · 2005. Ápr. 6. (Sze), 21.54
A cikkben lévő RewriteRule-t használva:
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?q=$1 [QSA]


ha ezt a kérést küldöm az Apache-nak:
http://localhost/ize///bigyo////

Akkor az index.php fájlban kiíratva:
var_dump($_SERVER['QUERY_STRING']);
var_dump($_SERVER['REQUEST_URI']);


Az eredmény ilyesmi:
string(12) "q=ize/bigyo/"
string(16) "/ize///bigyo////"


Tehát a több egymást követő perjelből egyet csinál az Apache, tudja esetleg vki, hogy ezt miért így csinálja, q értéke miért nem a "ize///bigyo////" lesz?

Attila
27

melyik a beállítás ami

Off- · 2005. Jún. 20. (H), 15.28
melyik a beállítás ami miatt az elso PATH_INFO -s modszer nem mukodik? vagy ez webserver fuggő ?

itthon ment (apache 2.0.54), de pl ingyenes tárhelyeken (uw,fw,atw) nem. miert ?
28

hogyhogy nem működik?

Hojtsy Gábor · 2005. Jún. 20. (H), 15.32
Most megkímélnélek attól, hogy zengzetes ötleteimet felvázoljam, hogy miként jelentkezhet, hogy nem működik. Talán ha leírnád, hogy mi a hibajelenség (mi van a PATH_INFO értékben), akkor lehetne segíteni...
29

uhh, hát ezt a kommentet

Off- · 2005. Jún. 20. (H), 15.49
uhh, hát ezt a kommentet gyorsan észrevetted :D

hát ez az, hogy semmi.

http://valamicim.fw.hu/rovidcimek.php/12 - erre 404es hiba jelentkezik az általam kiprobalt tárhelyeken

http://localhost/rovidcimek.php/12 - itthon meg jo és természetesen a PATH_INFO /12.
31

nem hiszem, hogy segít

Hojtsy Gábor · 2005. Jún. 20. (H), 17.29
Ingyenes szolgáltatóknál általában nem szokott segíteni a korlátozás okának ismerete, ha ki van kapcsolva valami. Mindenesetre Apache 2 esetén az AcceptPathInfo beállítást használható arra, hogy a PATH_INFO fogadását szabályozzák.
30

ingyenes?

Granc Róbert · 2005. Jún. 20. (H), 16.37
Ingyenes tárhelyeken sok mindent korlátoznak, a leírásukban nézz körül hogy mik vannak tiltva.

r.
32

phpinfo

kgyt · 2005. Jún. 21. (K), 20.07
Tegyél fel egy fájlt a tárhelyre a fenti függvénnyel, és azon teszteld...


--
Szeretettel: Károly György Tamás
kgyt&kgyt.hu - http://kgyt.hu
33

Egy kis segítség a RewriteRule-hoz

Anonymous · 2005. Okt. 18. (K), 21.14
Először is a cikk nagyon pöpec!

Már elég régóta szeretném megoldani egy otthoni apache szerveren hogy pl a 2000.rock.konyvek.home.hu web círe a következő dokumentumot adja be /www/htdocs/konyvek/rock/2000 mintha ezt adtam volna meg hogy home.hu/konyvek/2000 valamint ha igy szerepel www.2005.rock.konyvek.home.hu akkor a www-t ne vegye figyelembe. És ez persze dinamikus az az ha létrehozok egy könyvtárat akkor az el lehessen érni az előbb említett módon.
Az világos hogy a home.hu/stb/valami ben hogy tudom módosítani a /stb/valamit de a host -ot nem. Egy kis példa jól jönne.
34

Közben megoldottam!

Anonymous · 2005. Okt. 19. (Sze), 01.38

# Ezt egy Windows XP alatt működtetett Xampp (apache+php+mysql) webszerveren próbáltam
# a localhost-on (az az 127.0.0.1) és itt működött
# ha valaki nem akar DNS szervert felrakni az a C:\WINDOWS\system32\drivers\etc\hosts
# fájlba írjon ip host név társításokat a köv képpen: 
# 127.0.0.1     www.home.hu
# egyébként én a Simple DNS el próbáltam

# Bemásolni a httpd.conf -ba

NameVirtualHost 127.0.0.1:80

<VirtualHost 127.0.0.1:80>
	ServerAdmin tobiaspm##kukac##vodafone.hu
	DocumentRoot C:/apachefriends/xampp/htdocs/rewrite_teszt
	ServerName home.hu
	ServerAlias *.home.hu

# A Rewrite -ot bekapcsolom	
	RewriteEngine on
	RewriteLog logs/rewite.log.txt
	RewriteLogLevel 3

# Figyelmen kívül hagyom az ilyen webcímeket: www.home.hu/webalizer vagy www.home.hu/pdf/tesz.php
	RewriteCond %{REQUEST_URI} !^/(webalizer|phpmyadmin|excel|pdf|csimcache|icons|cgi-bin|error).*$

# A %{HTTP_HOST} a host nevet adja és figyelmen kívül hagyom a home.hu -t	
	RewriteCond %{HTTP_HOST} !^(home\.hu)$

# Minden home.hu utó taggal rendelkező hostból használom az előtagot ezt reprezentálja %1
	RewriteCond %{HTTP_HOST} ^(.*)(\.home\.hu)$

# Most összerakom a host előtagot az uri résszel az az /valai vagy / valami/index.html
	RewriteRule ^(/.*)$ %1$1

	RewriteCond %{HTTP_HOST} !^(home\.hu)$
	RewriteCond %{REQUEST_URI} !^/(webalizer|phpmyadmin|excel|pdf|csimcache|icons|cgi-bin|error).*$

# Most az első pont előtti szót áthelyezem közvetlenül az uri rész elé, 
#   majd ez elé egy / jelet és végül az első pont és az uri közötti rész rakom legelőrre
# az [N] opció egy ciklust képez a megadott reguláris kifejezés ismétlésére,
#   így érem el, a host tagok egy fordított "könyvtár" struktúrát alkossanak
	RewriteRule ^([^./]+)(\.)([^/]+)(.*)$ $3/$1$4     [N]
	
	RewriteCond %{HTTP_HOST} !^(home\.hu)$
	RewriteCond %{REQUEST_URI} !^/icons.*$

# Legvégül mindezek elé kell egy / jel mer így lesz olyan a webcímünk, hogy home.hu/valami/www
	RewriteRule ^(.*)$ /$1                            [QSA]

	RewriteCond %{HTTP_HOST} ^(home\.hu)$
	RewriteCond %{REQUEST_URI} !^/(webalizer|phpmyadmin|excel|pdf|csimcache|icons|cgi-bin|error).*$

# És hogy a home.hu -nk is működjön
	RewriteRule ^(.*)$ $1				  [QSA] 						



</VirtualHost>
36

IE gond - ErrorDocument használatakor

Anonymous · 2006. Jún. 10. (Szo), 12.54
Üdv mindenkinek!

Az ErrorDocument módszert választottam, mivel a szerveren nincs rewrite modul sajnos.
Firefox-al és Operával gond nélkül müködik is, viszont IE-vel HTTP 404-es üzenet ad vissza....

Valakinek valami építő jellegű ötlete?
37

HTTP kód

attlad · 2006. Jún. 10. (Szo), 13.23
Beállítottad 200-ra a válasz HTTP kódot?
39

RewriteRule érdekesen

CommanderLee · 2007. Okt. 23. (K), 11.45
hy
én szeretnék egy .htaccess segítséget kérni
a felállás a következő:
vagy egy file a htdocs\projekt\misc\bar mappában és én szeretnék írni rá egy htaccess-t, hogy a www.XY.hu/projekt/misc/bar/forwarder/23454-23.png-t átalakítsa www.XY.hu/projekt/misc/bar/forwarder/index.php?id=23454&type=23 -ra
ja és a projekt/misc/bar/forwarder/index.php meghívja include-al a projekt/misc/bar/index.php-t, de úgy hogy a GET metódussal megkapott paramétert feldolgozza a meghívása elött
lehetséges ezt valahogy megcsinálni, vagy értelmetlenül írtam az egészet?
kérlek segítsetek!
40

Légyszíves magyarul írj!

Dualon · 2007. Okt. 23. (K), 16.03
Szia!

Légyszíves próbáld meg betartani a magyar nyelv legalább alapvető szabályait. A helyes központozással, normális szavakkal (a hy például micsoda?), tagolt, nagy- és kisbetűs mondatokkal, stb. társaid tiszteled meg - vagyis azokat, akiktől segítséget kérsz.

Lehetséges, amit elképzeltél. Kicsit többet kellene tudnunk a környezetről, de feltételezve az Apache szervert, nézz utána a mod_rewrite modulnak, valamint ehhez kapcsolódóan a RewriteBase-nek, illetve a reguláris kifejezéseknek. Utóbbi táján azt kell megoldanod, hogy az X számjegyből, majd egy kötőjelből, illetve további számjegyekből, valamint .png karaktersorból álló stringet darabold úgy, hogy számjegyek, kötőjel, számjegyek (maradék elvetése) részeid legyenek.

Lehetséges, hogy a mod_rewrite működéséhez külön engedélyezned kell a .htaccess állományok figyelembe vételét, ennek pontos menete szerverkörnyezet-függő.

Netszerte számtalan oktatóanyag található, de ez például mintha épp a Te problémád feszegetné. Magyar anyagokhoz Google a barátod.

Egy-két praktikus tanács, ami valószínűleg nem derül majd ki a tutorialokból:
- Az egész procedúra nyilván használ erőforrásokat; minél nagyobb és komplexebb a .htaccess állomány, annál többet "eszik".
- Rosszul beállított szervernél az egész vasat megfektetheted egy hibás .htaccess-szel, úgyhogy illik vele otthon kísérletezni.
- Otthoni devkörnyezetben ne feledd újraindítani a szervert, miután engedélyezted a .htaccess-t
- Ingyenes tárhelyek általában nem engedélyezik .htaccess használatát.
41

Köszönöm válaszod!

CommanderLee · 2007. Okt. 24. (Sze), 15.32
Köszönöm, hogy válaszoltál, és bocsánat a helyesírásomért és a többiért. Most tisztábban írom meg a dolgot.
Elméletileg egy olyan .htaccess fájlt kéne írni, ami átad egy számsort egy .php fájlnak GET metódussal.
A probléma az, hogy nem a htdocs mappában található, hanem 3 mappával lejjebb.
Azt szeretném elérni, hogy a www.XY.hu/mappa/megegymappa/bar/forwarder/23454-23.png url-t vizsgálja meg, és a számsort küldje el a feldolgozó .php-nek.
Elméletben így nézne ki:

Options +FollowSymLinks

RewriteEngine on
RewriteRule ^(.*)/(.*)-(.*).png$ index.php?id=$2&type=$3 [L]
RewriteRule ^(.*)-(.*).png$ index.php?id=$1&type=$2 [L]

De az a probléma, hogy nem tudom, hogy értessem meg vele, a mappalokációt, ami persze nem álladnó.
A saját gépemen futtatom a .php szkripteket (xampp segítségével), de hem szeretném, ha mappafüggő lenne (projekt/misc/bar/forwarder/ stb....).
Lécci és persze ha nem gond írj egy kis scriptet, mert már kész vagyok... :(
42

kérés

lepke · 2007. Nov. 26. (H), 22.19
én a htaccesshöz egyáltalán nem értek, ezért azt sem tudom, hogy a változókra meg az egyes dolgokra hogy tudok hivatkozni benne.
# Apache Web Server Version 2.2.4
# PHP Script Language Version 5.2.3
# MySQL Database Version 5.0.45

velük dolgozom.
a nah pl h a localhost/site/alap.php?oldal=naplo
ra szeretnék hivatkozni azt hogy teszem?
én ezzel próbálkoztam:

<IfModule mod_rewrite.c>  
RewriteEngine on
RewriteBase /site  
RewriteCond %{REQUEST_FILENAME} !-f  
RewriteCond %{REQUEST_FILENAME} !-d  
RewriteRule ^(.*)$ alap.php?oldal=$1 [QSA]
</IfModule>  
és hogyha eztán pl arra lesz szükségem hogy
alap.php?oldal=naplo&bejegyzes=vasarnapi_ebed
ezt hogy tom?
Ha ezt megmondanátok konkrétan minden problémám megoldódna?
43

A többit a PHP-ban

Joó Ádám · 2007. Nov. 26. (H), 23.02
A legegyszerűbb az, ha a

<IfModule mod_rewrite.c>
    RewriteEngine on
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule ^(.*)$ index.php
</IfModule>
szabályt használod.
A megadott elérési utat aztán a $_SERVER['REQUEST_URI'] változóban találod, amit utána tetszés szerint felhasználhatsz.
44

hm

lepke · 2007. Nov. 27. (K), 17.24
ekkor minden css-es formázásom eltűnik.
egyébként már megy
45

URL Rewrite

Castor87 · 2007. Dec. 31. (H), 04.25
Üdv!
Én a 4. verziót választottam (4: URL Rewrite). A példa alapján addig el is jutottam, hogy a
valami.hu/hirek címre egy case segítségével kiírja a "hírek" szót.

Azt szeretném megkérdezni hogy a híreken belül hogy lehet egy adott hírt kiírni?
Tehát valami.hu/hirek/3 címre a hármas számú hírt írja ki. Maga a hír lekérdezéssel (sql-ből) nincs problémám, csak nem látom át még annyira az egész rövid webcímes megoldást. Hogyan tudnám kinyerni a webcímből azt a számot, amelyik megadja az adott hír (nevezzük így) id számát?

Legjobb az lenne, ha nem konkrétan erre a példámra kapnék választ, hanem általánosan hogy lehet egymásra/egymásba építeni a linkeket?

Feltételezem a megoldást SWITCH-en belüli SWITCH-ek lesznek, csak a változók kinyerésére lennék kíváncsi.
46

tedd fel új témakánt a kérdést

Hodicska Gergely · 2007. Dec. 31. (H), 12.08
-
47

nem megy...

freakjester · 2008. Okt. 20. (H), 18.50
nekem igazábol még az sem megy hogy az adott könyvtárra érvényes AllowOverride a Fileinfo-t tartalmaza. Ezt a .htacces-be kell beírni így?

<Directory />
AllowOverride FileInfo
</Directory>

Több helyen is ovlastam hogy httpd.conf-ba kell írni. De akárhova, akárhogyam írom be, nekem a következő hibaüzenet jelenik meg: "Internal Server Error" és a tárhelyen akármit szeretnék elérni, csak ezt látom...

mit csináljak?

httpd.conf fájlt, nem is találok a tárhelyemen. ez normális?
48

Szolgáltatónál érdeklődj

Dualon · 2008. Okt. 20. (H), 20.31
A .htaccess (egész pontosan a mod_rewrite modul) engedélyezését a szolgáltatódtól kell kérni.
A helyzetet úgy tudod felmérni, hogy lefuttatod a phpinfo()-t, és megnézed a kimenetét:
<?php
echo phpinfo();
?>
Az így kapott oldalon keresd meg az Apache handlerek szekciójában a "Loaded Modules" sort, és ott kell (kéne) szerepelnie a mod_rewrite-nak a felsorolásban.
Egyáltalán akkor érdemes elkezdeni foglalkozni a rövid webcímek kialakításával, ha ez megvan (még akkor sem 100%, hogy megy, de valószínű).

Kérlek, engedj meg néhány megjegyzést még:
1. Illik saját fejlesztői szerveren kísérletezni. Húzz fel egy apache-php-mysql hármast a gépedre, és avval játssz. Egyrészt ez alapvető korrektség a szolgáltatód felé, másrészt lehetőséged van sokkal gyorsabban és hatékonyabban tanulni, tapasztalni, harmadrészt kicsit tájékozottabb leszel abban a szerverkörnyezetben, amiben utána ügyködni szeretnél.
2. Kezdd el egészen egyszerű példákkal a tanulást. Építs egy pici próbascriptet, ami csak az átirányítást bizonyítja, a rövid webcímből kapott paramétereket kezeli.
3. Olvass utána az alábbi témáknak: Apache szerver telepítése és konfigurálása alapfokon, legegyszerűbb mod_rewrite opciók, HTTP státusz kódok (volt nemrég ehhez egy érintőlegesen kapcsolódó, remek cikk is), felhasználóbarát hibakezelés.
4. Feltételeztem, hogy Apache webszerverre dolgozol... :)
49

index.php?id=oldal1

dustman · 2010. Nov. 5. (P), 14.02
Üdv!
Engem az érdekelne mit ültessek a php kódba ahhoz hogy,
<?php
switch($_GET["id"])
 {
case "oldal1
include "oldal1.php";
break; 
default:
include("alap.php");
break;
}
?>
ezt a kódot lerövidítsem erre:
index.php/oldal1 
úgy hogy nem tudok operálni a .htaccess-el, csak a kódban tudom megadni, illetve helyettesíteni. Köszi.
50

ErrorDocument 404

reallalesz · 2011. Aug. 28. (V), 15.52
Üdv!
Én kipróbálás képpen az ErrorDocument-es megoldást választottam, mivel a rewrite nekem már bevált!!

Két hibám van!!
1. Nem tetszik, hogy az apache errorlog-ja televan!!

2. Ezt szeretném használni:
http://localhost/teszt/cikkek/40

ez azt eredményezné, hogy

"feldolgozo.php"
    
<?php  
    $URI = (isset($_SERVER['REQUEST_URI']) ? substr($_SERVER['REQUEST_URI'], 1) : '');  
    $URIparts = explode("/", $URI);  
      
    switch ($URIparts[0]) {   
      case 'cikkek':  
        status200();
        include("cikkek.php");
        $cikk = $URIparts[1];
      
        break;  
      default: 
        echo '404';
        break;  
    }  
      
    function status200()  
    {  
      @header("HTTP/1.1 200 OK");  
      @header("Status: 200 OK", TRUE, 200);  
    }  
az lenne a gondom, hogy amikor meghívom az url-t:
http://localhost/teszt/cikkek/1

akkor megváltozik erre:
http://localhost/teszt/feldolgozo.php
és eltűnik a REQUEST_URI!!

Mitől lehet ez?

RealLalesz