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 11942×

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ů

8.5.2016 17:19 /Redakce Linuxsoft.cz
PR: Dne 26.5.2016 proběhne v Praze konference Cloud computing v praxi. Tématy bude např. nejnovější trendy v oblasti cloudu a cloudových řešení, cloudové služby, infrastruktura cloudu, efektivní využití cloudu, možné nástrahy cloudů a jak se jim vyhnout
Přidat komentář

21.4.2016 8:01 /František Kučera
Spolek OpenAlt zve na 127. distribuovaný sraz příznivců svobodného softwaru a otevřených technologií (hardware, 3D tisk, SDR, DIY, makers…), který se bude konat ve čtvrtek 28. dubna od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5).
Přidat komentář

2.3.2016 22:41 /Ondřej Čečák
Letošní ročník konference InstallFest již tento víkend!
Přidat komentář

14.2.2016 16:39 /Redakce Linuxsoft.cz
O víkendu 5. a 6. března 2016 proběhne na pražském Strahově 8. ročník tradiční konference InstallFest. Celkem za dva dny uvidíte ​30 přednášek​ a ​6 workshopů.
Přidat komentář

5.2.2016 17:38 /Petr Ježek
Utilitka z XFce "xfce4-power-manager" nejen umožňuje nastavení lhůty pro uspání či hybernaci, ale i zapínání a vypínání prezentačního módu pro nerušené sledování videí. Stačí ji nastavit v každém vybavenějším panelu a v jakémkoli nontiled WM/DE.
Přidat komentář

10.1.2016 11:32 /Pavel `Goldenfish' Kysilka
LinuxMarket změnil provozovatele. Nově jej provozuje Marek Pszczolka. Více info a detaily #1 a #2.
Přidat komentář

29.12.2015 11:38 /Ondřej Čečák
Ještě posledních pár dní můžete přidávat příspěvky nebo nápady na Install Fest 2016, který se bude konat 5. a 6. března 2016.
Přidat komentář

8.12.2015 11:36 /Petr Ježek
Logické se stává realitou. LibreOffice a Thunderbird se mají dle článku na Redditu stát protiváhou MS řešení (MS Office a Outlook).
Přidat komentář

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

> Poslední diskuze

7.5.2016 14:58 / Teodor Komárek
Soubory

20.4.2016 0:07 / Jakub Cleing
Sázkový panel PHP FUSION

9.4.2016 9:43 / jiwopene@gmail.com
Re: problém s dpkg a nemožností instalovat

9.4.2016 9:41 / jiwopene@gmail.com
Re: změna velikosti disk.oddílu

9.4.2016 9:40 / jiwopene@gmail.com
Re: Přenesení starého OS Win7 na virtuál v Debianu

Více ...

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