LINUXSOFT.cz Přeskoč levou lištu
Uživatel: Heslo:  
   CZUKPL

> php rewrite

Někdy se stane, že nemáme k dispozici na našem hostingu tzv. rewrite, nebo si jeho pravidla nemůžeme sami zpravovat (např. u lighttpd serveru). V jiných pokročilých webových programovacích jazycích je ale obvyklé, použít tabulku adres a handlerů na funkce, které takovou adresu (požadavek) obslouží.

13.11.2009 00:00 | Ondřej Tůma | Články autora | přečteno 3542×

Komerční sdělení: Pořádáme Kurzy PHP

404 - stránka (ne)nalezena

K tomu aby to všechno fungovalo, potřebujeme provozovat vlastní chybovou stránku pro obsluhu chyby 404 - tedy nenalezeno. To lze nastavit na serveru Apache i pomocí .htaccess souboru. Pokud máme tuto možnost zakázanou, je třeba kontaktovat administrátora serveru, a požádat ho o příslušné nastavení. Chybová stránka je pak volána pokaždé, když server nenalezne soubor odpovídající http požadavku. Před samotným hledáním samozřejmě server provádí řadu úkonů, mezi něž patří i provedení rewrite pravidel.

V případě že budeme veškeré řízení aplikace provádět přes tuto stránku, je třeba si uvědomit, že server automaticky vrací klientovi a loguje stav vyvolání stránky jako chybu 404, a je tedy takto vedena i ve statistikách generovaných právě z logu serveru. Aby k tomuto nedocházelo, je třeba server přesvědčit, v případě že požadavek je v pořádku) aby do logu a i klientovi vracel relevantní kód. Přesvědčit klienta je celkem snadné, je důležité co nejdříve zavolat příkaz header('HTTP/1.1 200 Ok'). V případě serveru Apache ovšem toto neovlivní kód který je logován, Teoreticky lze toto napravit funkcí http_send_status, toto ale nemám ověřené, navíc nejde o standardní funkci php, ale o funkci z PECL rozšíření.

dispatch table

A nyní co by měl dělat kód uložený v chybové stránce. Takový kód musí sám rozeznat http požadavek, resp. zadané url, a na základě vyhodnocení tohoto požadavku spustit příslušný kód. Toto v podstatě dělá i webový server, ten pokud ovšem nedokáže obsloužit takový požadavek, vrátí uživateli chybovou stránku, resp. pustí kód, který jí má vygenerovat. Naše chybová stránka, která duplikuje takové chování po svém pak může vypadat nějak takto:

<*php preg_match("([\w\/]*)",$_SERVER["REQUEST_URI"], $matches); $uri = $matches[0]; switch($uri){ case "/info": phpinfo(); break; case "/globals": header ('HTTP/1.1 200 Ok'); echo "<h1>PHP rewriter test to globals</h1>"; echo ""; foreach ($GLOBALS as $key => $val) echo ""; echo "
$key:$val
"; break; default: // header je zde teoreticky uplne zbytecny header('HTTP/1.1 404 not found'); echo "<h1>404 not found</h1>"; echo "Your request `$uri` is not handled!"; } php>

Tento kód nejprve pomocí regulárního výrazu získá konec zadané adresy, která vyvolá chybu 404. Následuje jednoduchý switch, který pro konkrétní požadavek spustí konkrétní kód. Výchozí default větev vrátí chybovou stránku s chybovým stavem 404, tedy opravdu nenalezeno :) Tento kód slouží pro ukázku a je tedy velmi jednoduchý. Regulární výraz použitý pro získání požadavku se dá rozhodně pořádně vylepšit a ani hlavička s návratovým kódem není použita všude kde by měla, a už rozhodně ne pořádně.

Kód by mohl být vylepšen o celou řadu dalších programátorských technik, rozhodně by to mohlo být volání funkcí místo spouštění kódu. Kolem celého mechanismu by měla být vytvořena řada nějakých podpůrných funkcí právě ke správnému a jednotnému ošetření hlaviček, výstupu atd.

php rewrite

Pomocí fíglu s odchycením chyby serveru 404 lze vytvořit v php i "opravdový" mod_rewrite, budeme mu říkat php_rewrite ;) Kód by měl v podstatě získat adresu požadavku, a na základě nějakých pravidel přesměrovat na správný požadavek, který již bude obsloužen (tak jak to dělá webový server). Jedno z kouzel mod_rewrite ale je, že se v prohlížeči návštěvníka stránky adresa nezmění, i toho lze malým trikem dosáhnout, musíme ale opravdu vědět, co vlastně děláme. Následující kód přidává php_rewrite do CMS Morias, tedy již do hotového projektu.

<*php preg_match("([\w\/]*)",$_SERVER["REQUEST_URI"], $matches); $uri = $matches[0]; function rwrule($pattern, $target){ global $uri; $new_url = preg_replace('/'.$pattern.'/', $target, $uri); // z vyslende url, nakrmime superglobalni promenou _GET, ta neni vsupem // z prohlizece, proto ji musime vytvorit umele preg_match_all('(\w+=\w+)', $new_url, $query); foreach ($query[0] as $pair){ list($var,$val) = explode('=', $pair); $_GET[$var]=$val; } return $new_url; } $new_url = rwrule("^\/text\/([a-zA-Z0-9\\-_]*)$","/?module=morias_text&action=texts&seo=$1"); // tyto dva prikazy zpusobi bezne presmerovani //header ('HTTP/1.1 301 Temorary move'); //header ("Location: $new_url"); header ('HTTP/1.1 200 Ok'); require_once('./index.php'); php>

Co to vlastně dělá? Funkce rwrule dostane dva parametry, regulární výraz, který je použit na url a cíl regulárního výrazu, tedy stránku, která se má opravdu načíst. V kódu je trochu zmatek, aktuální verze ve skutečnosti nepošle prohlížeči požadavek na přesměrování, ale z nového url získaného rewrite pravidlem pomocí regulárního výrazu naplní super-globální proměnou _GET a přímo načte php soubor, který tento požadavek dál zpracuje, jako by to byl normální http požadavek.

Díky tomu, že nedojde k přesměrování, ale k podsunutí _GET hodnot jinému php scriptu, uživatel bude mít ve svém prohlížeči původní adresu, a php_rewrite tak začne fungovat tak jak je mod_rewrite často používán.

Závěrem

Oba příklady jsem zkoušel na serveru lighttpd, který právě trpí nedostatkem, kdy si uživatel sám nemůže upravovat rewrite pravidla, pokud nemá přístup přímo ke konfiguraci serveru. Otázka jak moc je, nebo není vhodné, takto rewrite řešit nechám na laskavém čtenáři, či diskutujícím. Kdo se ale do této magie pustí, měl by pamatovat na záludnosti regulárních výrazů, ty bude třeba určitě pořádně vyladit, aby obsloužily správně všechny adresy.

Verze pro tisk

pridej.cz

 

DISKUZE

.htaccess 13.11.2009 11:42 Radim Kolář
  L Re: .htaccess 18.11.2009 21:05 Ondřej Čečák
    L Re: .htaccess 18.11.2009 23:32 Aleš Hakl
      L Re: .htaccess 19.11.2009 08:58 Ondřej Tůma
        L Re: .htaccess 20.11.2009 01:33 Aleš Hakl




Příspívat do diskuze mohou pouze registrovaní uživatelé.
> Vyhledávání software
> Vyhledávání článků
> Služby
Administrace serverů
Od 350 Kč/hod
Server housing
Od 1000 Kč/1U

10.9.2010 6:44 /MaReK Olšavský
Platforma ARM nestagnuje a její tvůrce intenzivně pracuje i na prosazení mimo segment mobilních zařízení. ARM nabídl nový Cortex-A15 k licencování výrobcům. Nová generace dokáže nabídnout frekvence až 2,5 GHz při stejné spotřebě, jako současné generace, takže výkonu bude dost i pro servery.
Přidat komentář

10.9.2010 6:30 /MaReK Olšavský
Na stránkách Phoronix vyšla krátká ingormace o možnosti ukončení vývoje Linuxu 2.4. Jádro už je velmi zastaralé a drtivá většina distribucí používá moderní řadu 2.6.
Přidat komentář

8.9.2010 6:24 /MaReK Olšavský
Na stránkách OMG Ubuntu vyšel rozhovor s Fredericem Menem, který stál u vzniku GNOME.
Přidat komentář

8.9.2010 6:16 /MaReK Olšavský
Vylepšování gdb se dostalo k dalšímu milníku, kterým je podpora jazyka D, do nejž jsou vkládánny velké naděje.
Přidat komentář

7.9.2010 8:00 /MaReK Olšavský
Pokud chcete někoho z platformy MS Windows přemigrovat na GNU/Linux (eventuálně na jiný Un*x), mohl by Vám pomoci krátký blogspot s 5 tipy pro „jemný“ přechod, kterými usnadníte život nováčkům ve svobodném systému.
Přidat komentář

   Více ...   Přidat zprávičku

> Poslední diskuze

9.9.2010 11:41 / Petr Hložek
Stránkování dat z MySQL v aplikaci

8.9.2010 16:03 / bugme NOT
Re: Přesouvání-kopírování souborů v Ubuntu

8.9.2010 16:00 / bugme NOT
Re: Soft na virtual sieť

8.9.2010 9:24 / student
niečo pre &quot;no guru&quot; by nebolo

7.9.2010 23:43 / Petr Ježek
Re: Generator BSD licenci

Více ...

ISSN 1801-3805 | Prague hotels | Provozovatel: Pavel Kysilka, IČ: 72868490 (2003-2010) | mail at linuxsoft dot cz | Design: www.megadesign.cz | Textová verze