Back to site
Since 2004, our University project has become the Internet's most widespread web hosting directory. Here we like to talk a lot about web servers, web development, networking and security services. It is, after all, our expertise. To make things better we've launched this science section with the free access to educational resources and important scientific material translated to different languages.

Corz - više .htaccess saveta i trikova...

višee .htaccess saveta i trikova...

<ifModule>
još pametnih stvari ovde
</ifModule>
 

preusmeravanje i prepisivanje

"Sjajna stvar u mod_rewrite modulu je što vam pruža svu konfigurativnost i fleksibilnost Sendmaila. Loša osobina mod_rewrite modula je što vam pruža svu konfigurativnost i fleksibilnost Sendmaila"

- Brian Behlendorf, Apache Groupa
 

Jedan od najmoćnijih trikova .htaccess hakera je njegova sposobnost prepisivanja URL adresa. To nam omogućava da izvršimo moćne manipulacije na našim linkovima; korisne stvari kao što je pretvaranje veoma dugačke URL adrese u kratku, slatku URL adresu, pretvaranje dinamički ?generated=page&URL's u /lake/ravne/linkove, preusmeravanje izgubljenih stranica, sprečavanje aktivnog povezivanja (hot-linking), automatsko prevođenje jezika i mnogo, mnogo više.

Da ne bude zabune, mod_rewrite je složen. To nije brz, lagan tehnički zalogajcicć, nije cak ni tema brzog vikend-kursa. Video sam da momci rade neke prilično dobre stvari sa mod_rewrite, ali uz sve poštovanje i priznanje tom paklenom operatoru, Ralf S. Engelschallu, samom autoru magičnog modula, moram priznati da mi veći deo svega toga još uvek deluje poput vudu magije.

Način na koji pravila u jednom trenutku funkcionišu, a u sledećem izgleda da ne rade, način na koji pretraživac i druga međumrežna keš memorija ostvaruju interakciju sa pravilima i test-pravilima, često izluđuje i zbunjuje. Kada osetim potrebu da potpuno izbacim svoj um iz njegovog ustaljenog okvira, zanimam se mod_rewrite mogulom!

Posle svega, on funkcioniše i, iako ne planiram skoro da odem na taj brzi vikend-kurs, ipak sam i sam preuzeo nekoliko malih trikova dok sam se zanimao web serverima i sajtovima, ovim ovde...

Plan je da jednostavno ubacim neke privlačne stvari, primere, nešto što se pokazalo korisnim i što je radilo na više različito podešenih servera; Apache je svuda u mom LAN-u, stalno nailazim na stare .htaccess fajlove zatrpane prošlim eksperimentima prepisivanja koji su bili uspešni; i dodajem ih na listu, ili su bili tužno neuspešni; i sve više bivam iznenađen ovih dana time što sada tačno mogu videti i zašto!

Vrlo malo toga ovde je moj sopstveni izum. Cak su i bitovi koje sam sam shvatio već bili dobro dokumentovani, samo ja nisam razumeo dokumenta ili nisam mogao da ih nađem. Ponekad samo posmatranje stvari iz različitog ugla može biti značajno, pa tako možda i ovaj skromni pokušaj na URL Rewritingu može biti od neke koristi. Ja ga, naravno, pišem za sebe. Ali ipak mi pripadaju zasluge...

# time to get dynamic, see..
RewriteRule (.*)\.htm $1.php
 

otpočinjanje prepisivanja...

Svaki put kada koristite mod_rewrite (Apache deo koji radi svu tu magiju), morate da...


pre bilo kakvog ReWrite pravila. Napomena: +FollowSymLinks mora biti omogucen da bi bilo koje pravilo funkcionisalo, to je sigurnosni zahtev mehanizma za upisivanje. Normalno je to omoguceno u osnovnom modulu i ne morate da ga dodajete, ali ni۴a ne ko۴a da to uradite, a ja cu to ubaciti u sve primere na ovoj stranici, za svaki slucaj*.

Sledeći red jednostavno uključuje mehanizam za prepisivanje za taj folder. Ako je ta direktiva u vašem glavnom .htaccess fajlu, tada je ReWriter teoretski omogućen za ceo vaš sajt, ali je mudro da uvek dodate taj red pre nego što napišete bilo kakva preusmeravanja, bilo gde.

* Iako malo verovatno, vaš matični racunar može imati omogućen +FollowSymLinks na osnovnom nivou, a da ipak ne odobri njegovo dodavanje u .htaccess; u tom slučaju će dodavanje +FollowSymLinks slomiti vaša podešavanja (verovatno će biti greška 500), te ga samo uklonite i vaša pravila će dobro raditi.

Važno: Iako se neke od direktiva na ovoj stranici mogu pojaviti kao podeljene na dva reda u vašem pretraživacu, u vašem .htaccess fajlu, one moraju da postoje u jednom redu. Ako prevucčete-izaberete i kopirate direktive na ovu stranicu, one bi trebalo da se iskopiraju sasvim dobro u svakom editoru teksta.
 

Jednostavno prepisivanje

Jednostavno rečeno, Apache skenira sve dolazeće URL zahteve, traži odgovarajuće parove u našem .htaccess fajlu i prepisuje te URL parnjake u ono što odredimo. Nešto poput ovoga...

svi zahtevi ka bilošta.htm bice poslati u bilo šta.php:
Options +FollowSymlinks
RewriteEngine on
RewriteRule ^(.*)\.htm$ $1.php [NC]

Zgodno za svakoga ko ažurira sajt sa statičkih htm (možete upotrebiti .html, or .htm(.*), .htm? itd.) na dinamičke php stranice; zahtevi u starim stranicama automatski se prepisuju u nove url-e. I niko ništa ne primećuje, posetioci i mehanizmi za pretraživanje mogu pristupiti vašem sadržaju na bilo koji od dva načina. Zadržite to pravilo. Kako dodatni bonus, to nam omogućava da lako podelimo php kod i uključenu html strukturu na dva odvojena fajla, dobra ideja; mnogo olakšava uređivanje i ažuriranje. [NC] deo na kraju znači "No Case" ili "case insensitive" (neosetljiv na velika i mala slova); više o ovim promenama kasnije.

Narod može da se poveže na bilošta.htm ili bilošta.php ali uvek dobijaju bilošta.php koji je u njihovom pretračivacu, a to funkcioniše čak i kada bilošta.htm ne postoji! Ali sada već lutam...

Kao što se vidi, malo je varljivo; ljudi će i dalje imati bilošta.htm u adresnom polju svog pretračivaca i dalje će beležiti vašu staru .htm URL adresu. I mehanizmi za pretraživanje će, takode, nastaviti da indeksuju vaše linkove kao .htm, a neki čak govore da će vas mehanizmi za pretraživanje kazniti zbog ponude istog sadržaja sa dva različita mesta. To može i ne mora da vam smeta, ali ako vam smeta, mod_rewrite može izvesti još malo magije...

ovo će uraditi "pravo" spoljno preusmeravanje:
Options +FollowSymlinks
RewriteEngine on
RewriteRule ^(.+)\.htm$ http://corz.org/$1.php [R,NC]

Ovaj put naređujemo mod_rewrite da uradi odgovarajuće spoljno preusmeravanje, tzv. "redirekciju". Sada, umesto prepisivanja pozadine, pretračivac korisnika se fizički preusmerava na novu URL i whatever.php se pojavljuje u adresnom polju njihovog pretraživaca - mehanizmi za pretraživanje i ostali programi tragači će automatski ažurirati svoje linkove na .php verzije; svi su na dobitku. Ni vi ne morate žuriti sa ažuriranjem.

Napomena: ako koristite samo [R] to podrazumeva slanje HTTP "PRIVREMENO PREMEŠTEN" redirekcije, tzv. "302". Ali možete slati i druge kodove, ovako...

ovo vrši sasvim isto kao i prethodni primer Rewrite Rule pravila.
RewriteRule ^(.+)\.htm$ http://corz.org/$1.php [R=302,NC]

Оk, poslao sam potpuno isti kod, ali nisam morao. Za detalje o mnogim 30* kodovima odgovora koje možete poslati, pogledajte ovde. Izgleda da većina želi da pošalje 301, tzv. "TRAJNO PREMEŠTEN”.

Napomena: ako dodate “L” zastavu u miks; što znači “Poslednje pravilo”, npr. [R=302,NC,L]; Apache će zaustaviti obradu pravila zbog tog razloga u tom trenutku, što može i ne mora biti ono što želite. U svakom slučaju korisno je znati.
 

ne tako jednostavno prepisivanje...ravni (flat) linkovi i ostalo

Možda ste primetili da navedeni primeri koriste rеgularni izraz zа podudaranje sa varijablama. To jednostavno znači... uparite unutrašnji deo (.+) i upotrebite ga da biste izgradili "$1" u novom URL-u. Drugim rečima, (.+) = $1 može imati višestruke (.+) delove i za svaki, mod_rewrite će automatski kreirati uparene $1, $2, $3 itd. u vašem ciljnom (tzv.’zamenskom’) URL-u. Ta olakšica nam omogućava da izvodimo razne trikove, a najčešći je stvaranje “ravnih linkova”...

Čak i slatki kratki link kao što je http://mysite/grab?file=my.zip је nekima previše ružan i ništa osim pravog starog stabilnog domena/putanje/ravnog/linka neće biti dovoljno dobro. Na sreću , mod_rewrite olakšava konvertovanje URL-a sa upitnim nizovima i višestrukim varijablama u tačno ovo, nešto poput...

složenije pravilo prepisivanja:
Options +FollowSymlinks
RewriteEngine on
RewriteRule ^files/([^/]+)/([^/]+).zip /download.php?section=$1&file=$2 [NC]

dozvolilo bi vam da predstavite ovaj link kao..

  http://mysite/files/games/hoopy.zip

a da se u pozadini to transparentno prevede, sa strane servera, u...

  http://mysite/download.php?section=games&file=hoopy

što bi neka skripta mogla da obrade. Kao što vidite, mnogi mehanizmi za pretraživanje jednostavno ne prate naše ?generisane=linkove, pa ako napravite generisane stranice, to će biti od koristi. Ipak, samo tupavi mehanizmi za pretraživanje ne umeju da rukuju ovakvim linkovima; moramo se zapitati... da li zaista želimo da nas tupavi mehanizmi za pretraživanje izlistaju? Google će baratati dobrim brojem parametara u vašoj URL adresi bez ikakvih problema, a (gladni, gladni) msn-bot ne prezaju ni pred čim da bi dobili tu stranicu, ponekad iznova i iznova i iznova...

Ja lično osećam da su mehanizmi za pretraživanje ti koji bi trebalo da teže da održe korak sa modernim web tehnologijama, drugim rečima, ne bi trebalo da ih namerno srozavamo. Ali to je moje mišljenje. Mnogi korisnici će prednost dati /fajlovima/igricama/hoopy.zip nad /download.php?section=games&file=hoopy ali meni je svejedno. Kao što mi je neko nedavno napomenuo, predstavljanje linkova kao standardnih/ravnih/putanja znači da je malo verovatno da ćete navesti ljude da greše prilikom upisivanja URL-a, pa bi nešto poput...

јоš složenije pravilo prepisivanja:
Options +FollowSymlinks
RewriteEngine on
RewriteRule ^blog/([0-9]+)-([a-z]+) http://corz.org/blog/index.php?archive=$1-$2 [NC]

bilo lep trik koji će svakom omogućiti da pristupi arhivima na mom blogu tako što će uneti...

 http://corz.org/blog/2003-nov

u svoj pretraživač i automagijski ga transformisati sa strane servera u...

 http://corz.org/blog/index.php?archive=2003-nov

koji bi corzblog razumeo. Lako je videti da uz malo mašte, i osnovno razumevanje posix regularnih izraza, možete izvesti neke prilično dobre URL manipulacije.

Evo i osnova regexp-a (prošireno iz Apache mod_rewrite dokumentacije)..
 

Izlaz:

	\char escape that particular char

		For instance to specify special characters.. [].()\ etc.

	Text:

	.             Any single character  (on its own = the entire URI)
	[chars]       Character class: One of following chars
	[^chars]      Character class: None of following chars
	text1|text2   Alternative: text1 or text2 (i.e. "or")

		e.g. [^/] matches any character except /
			 (foo|bar)\.html matches foo.html and bar.html

	Kvantifikatori:

	? 0 or 1 of the preceding text
	* 0 or N of the preceding text  (hungry)
	+ 1 or N of the preceding text

		e.g. (.+)\.html? matches foo.htm and foo.html
			 (foo)?bar\.html matches bar.html and foobar.html

	Grupisanje:

	(text)  Grouping of text

		Either to set the borders of an alternative or
		for making backreferences where the nthe group can 
		be used on the target of a RewriteRule with $n

		e.g.  ^(.*)\.html foo.php?bar=$1

	Sidrište:

	^    Start of line anchor
	$    End   of line anchor

		An anchor explicitly states that the character right next to it MUST 
		be either the very first character ("^"), or the very last character ("$")
		of the URI string to match against the pattern, e.g.. 
		
		^foo(.*) matches foo and foobar but not eggfoo
		(.*)l$ matches fool and cool, but not foo
	
 

skraćivanje URL-a

Јedna od najčešćih upotreba mod_rewrite modula je skraćivanje URL-a. Kraće URL adrese se lakše pamte i, naravno, lakše kucaju. Primer...

pazite na regularni izrar:
Options +FollowSymlinks
RewriteEngine On
RewriteRule ^grab /public/files/download/download.php

оvo pravilo bi pretvorilo URL ovog korisnika...

  http://mysite/grab?file=my.zip

sa strane servera u...

  http://mysite/public/files/download/download.php?file=my.zip

što je mali trik koji sam, između ostalog, upotrebio za svoju distro mašinu. Svi vole kratke URL-e, a i vi ćete; koristeći tu tehniku možete da se premeštate/objavljujete/smeštate u arhivu/preuzimate na bilo koju lokaciju na vašem sajtu, dok će stari linkovi nastaviti da funkcionišu; jednostavno promenite vaš .htaccess fajl tako da reflektuje novu lokaciju. Uredite jedan red, urađeno - lepo - znači da iako su neke stvari smeštene negde duboko u vašem sajtu, svejedno možete imati dobre linkove kao što je ovaj... /trueview/sample.php i ovaj; linkovi koji nisu samo kratki već su i obični..
 

snimanje varijabli

Udaranje (.*) na kraj zahtevanog dela ReWriteRule je sasvim u redu kada se koristi jednostavna $_GET varijabla, ali ponekad ćete hteti da uradite neke teže stvari, kao što je kaptaža određenih varijabli i njihovo konvertovanje u druge varijable u ciljnoj URL adresi. Ili nešto drugo...

Kada snimate varijable, prvo što treba da znate o tome jeste da [QSA] zastava koja jednostavno označava sve originalne varijable nazad na kraj ciljne url adrese. To može biti sve što vam je potrebno i za jednostavne prepisivače će se desiti automatski. Druga stvar je %{QUERY_STRING}, Apache serverski niz iz kojeg možemo snimiti varijable koristeći jednostavne RewriteCond (tzv. uslovne) iskaze..

RewriteCond je sličan sa ako...onda...radi u mnogim programskim jezicima. Ako je neki uslov istinit, onda uradite prepis koji sledi...

U sledećem primeru RewriteCond iskaz proverava da li znakovni niz upita ima foo skup varijabli i da li snima njihovu vrednost dok je tu. Drugim rečima, samo će zahtevi za /grab koji imaju foo skup varijabli biti prepisani, a dok smo tu, takođe menjamo foo u bar, samo zato što možemo...

kaptaža $_GET varijable:
Options +FollowSymlinks
RewriteEngine On
RewriteCond %{QUERY_STRING} foo=(.*)
RewriteRule ^grab(.*) /page.php?bar=%1

bi prevela link/zahtev korisnika za...

http://domain.com/grab?foo=bar

sa strane servera u...

http://domain.com/page.php?bar=bar

Što će reći da će u pretraživač korisnika biti uneto page.php (bez [R] zastave u RewriteRule, njihovo adresno polje će i dalje biti /grab?foo=bar). bar varijabla će biti dostupna za vaš skript kada njena vrednost bude podešena na bar. Ta varijabla je magično kreirana jednostavnom upotrebom regularnog ? u odredištu RewriteRule-, označavajući na prvoj snimljenoj povratnoj referenci, %1.. ?bar=%1

Napomena kаkо koristimo % znak da bismo odredili varijable snimljene u RewriteCond iskazu, tzv. “Backreferences”. To je isto kao korišćenje $1 za određivanje nabrojanih povratnih referenci snimljenih u RewriteRule putanji, te osim nizova koji su snimljeni unutar RewriteCond iskaza, koristimo % umesto $. Jednostavno..

Možete koristiti [QSA] zastavu kao dodatak manipulaciji nizovima upita, i spojiti ih. U sledećem primeru vrednost foo postaje direktorijum u ciljnoj URL adresi a fajl varijable se magično stvara. Originalni niz upita se zatim povratno označava na kraju cele stvari...
QSA Overkill!
Options +FollowSymlinks
RewriteEngine On
RewriteCond %{QUERY_STRING} foo=(.+)
RewriteRule ^grab/(.*) /%1/index.php?file=$1 [QSA]

Tako se upit za...

http://domain.com/grab/foobar.zip?level=5&foo=bar

prevodi, sa strane servera, u...

http://domain.com/bar/index.php?file=foobar.zip&level=5&foo=bar

U zavisnosti od vaših potreba, možete upotrebiti i ravne linkove i dinamičke varijable zajedno, nešto poput ovoga bi moglo biti korisno..


Takođe, lako možete uraditi i suprotno, svući znakovni niz upita sa URL-a jednostavno stavljajući ? tačno na kraj ciljnog dela. Ovaj primer čini upravo to, a stvarni URL se ne dira...

samo demo!
Options +FollowSymlinks
RewriteEngine On
RewriteCond %{QUERY_STRING} .
RewriteRule foo.php(.*) /foo.php? [L]
RewriteCond iskaz dozvoljava da RewriteRule obradi samo zahteve koji imaju nešto u svom upitnom nizu, inače bismo završili na tom paklenom mestu, zaplašeni svim tim mod_rewriterima...beskrajna petlja. RewriteCond se često koristi ovako; kao sigurna mreža.

Ako je sve što tražite /jednostavan/ravan/link na strani servera.php?query=prevod varijable, upotrebite nešto poput ovoga..


 

cooler pristup odbijen

U prvom delu demonstrirao sam jednostavan mehanizam za odbijanje pristupa određenim fajlovima i folderima. Nevolja sa tim je način na koji naši korisnici dobijaju 403 grešku “odbijen pristup” što je slično kao da vam neko zalupi vrata pred nosem. Na sreću, mod_rewrite ponovo stiže u pomoć i omogućava nam da radimo manje bolne stvari. Jedan metod koji često koristim je preusmeravanje korisnika u roditeljski folder...

оni na to kažu "ha?...ahhh!”
# send them up!
Options +FollowSymlinks
RewriteEngine on
RewriteRule ^(.*)$ ../ [NC]

To odlično funkcioniše, iako može biti pomalo škakljivo sa URL adresama i možda ćete radije koristiti stabilniju lokaciju, čime će se izbeći potencijalni problemi u indeksovanim direktorijumima, u kojima se ljudi mogu upetljati...

prokleti! Оh!
# send them exactly there!
Options +FollowSymlinks
RewriteEngine on
RewriteRule ^(.*)$ /comms/hardware/router/ [NC]

Ponekad ćete samo želeti da odbijete pristup većini fajlova u direktorijumu, ali da dozvolite pristup za možda jedan ili dva fajla, ili vrste fajlova, lako...
odbij sa stilom!
# users can load only "special.zip", and the css and js files.
Options +FollowSymlinks
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !^(.+)\.css$
RewriteCond %{REQUEST_FILENAME} !^(.+)\.js$
RewriteCond %{REQUEST_FILENAME} !special.zip$
RewriteRule ^(.+)$ /chat/ [NC]

Ovde celu stvar odnosimo za jednu fazu dalje. Korisnici mogu pristupiti .css (stylesheet) i Javascript fajlovima bez problema, i fajlu pod nazivom "special.zip", ali zahtevi za bilo koju drugu vrstu fajla se trenutno preusmeravaju nazad na glavni "/chat/" direktorijum. Možete dodati onoliko vrsta koliko vam je potrebno. Takođe možete kompletirati vrste fajlova u jednom redu koristeći | (ili) sintaksu, iako su pojedinačni redovi možda čitljiviji..

Еvo šta se trenutno kuva u mom /inc/ direktorijumu..

sve-u-jednom kontrola...
RewriteEngine on
Options +FollowSymlinks
# allow access with no restrictions to local machine at 192.168.1.3
RewriteCond %{REMOTE_ADDR} !192.168.1.3
# allow access to all .css and .js in sub-directories..
RewriteCond %{REQUEST_URI} !\.css$
RewriteCond %{REQUEST_URI} !\.js$
# allow access to the files inside img/, but not a directory listing..
RewriteCond %{REQUEST_URI} !img/(.*)\.
# allow access to these particular files...
RewriteCond %{REQUEST_URI} !comments.php$
RewriteCond %{REQUEST_URI} !corzmail.php$
RewriteCond %{REQUEST_URI} !digitrack.php$
RewriteCond %{REQUEST_URI} !gd-verify.php$
RewriteCond %{REQUEST_URI} !post-dumper.php$
RewriteCond %{REQUEST_URI} !print.php$
RewriteCond %{REQUEST_URI} !source-dump.php$
RewriteCond %{REQUEST_URI} !textview.php$
RewriteRule ^(.*)$ / [R,NC,L]
 

Zabrana korisničkih agenata, refereri, script-kiddies i još više...

Postoje brojni valjani razlozi da se zabrani određeni zahtev za usisavanje izvora sa vašeg sajta; izvora koji bi mogli biti bolje usluženi validnim zainteresovanim korisnicima. To može biti agresivno skriptovanje dinamičkih stranica ili unutrašnji link sa lokacije sa kojom ne želite da budete povezani, ili možda internet upijač ili upravljač preuzimanja, bilo šta; .htaccess + mod_rewrite pruža načine da zaštitie vaš sadržaj od nepoželjnih “posetilaca”.

Osnovna formula je standardna ako-onda logika: ako zahtev zadovoljava određeni USLOV, onda PREPIŠITE zahtev. “Uslov” mogu biti razne stvari; možda zaglavlje referera koje šalju pretraživači (sajt sa kojeg su došli), ili stranica koju su tražili, ili određeni parametar upita, ili vrsta klijenta (pretraživač itd.) kojeg koriste, ili bilo koja druga informacija koju je Apache prikačio za zahtev. Evo primera koji će odbiti pristup u “Teleport Pro”, upravljač preuzimanja za koji je poznato da mnogo usisava..

Kоme je potrebna lokalna kopija, kada ja ovde?...
RewriteCond %{HTTP_USER_AGENT} ^Teleport\ Pro [NC]
RewriteRule . abuse.txt [L]

To je vaš sajt, i poput vašeg doma, imate svako pravo da izvršite kontrolu nad tim ko u njega ulazi. Možete imati ogromnu listu korisničkhi agenata za koje radije ne biste voleli da koriste vaš propusni opseg; pa upotrebite [OR] zastavu, i poređajte ih...

mаlo belog luka za internet vampire...
RewriteCond %{HTTP_USER_AGENT} ^BackWeb [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Bandit [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^BatchFTP [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^BecomeBot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^BlackWidow [NC,OR]
# etc..
RewriteCond %{HTTP_USER_AGENT} ^Net\ Vampire [NC]
RewriteRule . abuse.txt [L]

То čini osnovu onoga što obično postane OGROMNA lista redova zabrane. Zapamtite, nismo ograničeni na nizove korisničkog agenta...

Upijači, h4x0rz, početnici, skripteri dinamičkih stranica i mnogo drugog...Kupite sada!
# why not come visit me directly?
RewriteCond %{HTTP_REFERER} \.opendirviewer\. [NC,OR]
# this prevents stoopid cross-site discovery attacks..
RewriteCond %{THE_REQUEST} \?\ HTTP/ [NC,OR]
# please stop pretending to be the Googlebot..
RewriteCond %{HTTP_REFERER} users\.skynet\.be.* [NC,OR]
# really, we need a special page for these twats..
RewriteCond %{QUERY_STRING} \=\|w\| [NC,OR]
RewriteCond %{THE_REQUEST} etc/passwd [NC,OR]
RewriteCond %{REQUEST_URI} owssvr\.dll [NC,OR]
# you can probably work these out..
RewriteCond %{QUERY_STRING} \=\|w\| [NC,OR]
RewriteCond %{THE_REQUEST} \/\*\ HTTP/ [NC,OR]
# etc..
RewriteCond %{HTTP_USER_AGENT} Sucker [NC]
RewriteRule . abuse.txt [L]

Na sreću, mod_rewrite može raščlaniti liste zabrana u milisekundama, pa slobodno budite detaljni i sveobuhvatni koliko je to potrebno..

Kao i uvek, snažno se preopručuje temeljno testiranje. Jednostavno pošaljite zahtev koji se podudara sa vašim uslovima i vidite šta će se desiti. I jo švažnije, normalni zahtevi, takođe. Firefox, Opera, Konqueror i većina drugih pretraživača omogućava vam da promenite niz korisničkog agenta; iako bi vam proces brzo postao dosadan u situaciji testiranja. Mnogo je bolje koristiti neku bolje dizajniranu alatku za slanje lažnih HTTP zahteva...

Nije suviše teško izmodelovati web zahtev na komandnoj liniji uz pomoć nekog starog korisničkog agenta, koristeći jezik za skriptovanje poput php ili Perl, ako su vam te stvari dostupne (čitaj; većina Linux/UNIX/BSD/itd. kao i većina drugih OS). Postoji mnogo onlajn primera. U stvari, možete brzo napraviti paket testova dizajniranih da ispitaju sva vaša pravila prepisa, uz evidentiranje rezultata i mnogo drugog, ako je potrebno. cURL je uvek koristan za ovakve poslove sve dok ne dodate cURL red zabrane!

Na Windows desktopu, Sam Spade može poslati jedinstveni lažirani zahtev u par klikova, zajedno sa gomilom sličnih zgodnih trikova, i uvek se pokaže neprocenjivim.
 

Nе dozvolite da bilo ko izvrši udar na vaš sajt!

Dok govorim o agresivnim web klijentima, verovatno ste primetili da mnogi klijenti (roboti, tragači, automatizovani upijači i slično)vole da prikriju informacije o svom korisničkim agentu, zapravo sve informacije, u pokušaju da obore vaš sajt na kolena i u obradi oštete vaše stranice bezbroj puta u sekundi. To nije dobro.

Ako vas interesuje način da pobedite oštećivanje web klijenata bez obzira na to ko se pretvaraju da jesu ili bilo da prihvate kolačiće ili bilo kakvu sličnu koještariju ili ne, i da zaštitie vredne serverske izvore za prave klijente, pogledajte: Anti-Hammer. Besplatno je.
 

sprečavanje hot-linkinga

Verovali ili ne, postoje webmasteri koji će, pre nego da smisle sopstveni sadržaj, ukrasti vaš. Zaista! Još gore, neće se potruditi ni da iskopiraju to na njihov server, samo će se povezati sa vašim sadržajem! Ne, to je istina, u stvari, to je nekad bilo uobičajeno. Danas većina ljudi želi da spreči takve stvari, a .htaccess je jedan od najboljih načina da se to uradi.

Ovo je jedna od onih direktiva gde su varijable trajanja u svojim granicama, ali nešto poput ovoga meni odgovara...

kаkо se samo usuđuju!
Options +FollowSymlinks
# no hot-linking
RewriteEngine On
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?corz\.org/ [NC]
RewriteCond %{REQUEST_URI} !hotlink\.(gif|png) [NC]
RewriteRule .*\.(gif|jpg|png)$ http://corz.org/img/hotlink.png [NC]

Možete videti poslednji red podeljen na dva, ali to je sve jedan red (sve direktive su na ovoj stranici). Pogledajmo na kratko šta oni rade...

Počinjemo omogućavanjem mehanizma za prepisivanje, kao i uvek.

Prvi RewriteCond red omogućava direktnim zahtevima (ne sa drugih stranica - “prazan referer”) da prođu bez problema. Sledeći red znači; ako pretraživač jeste poslao zaglavlje referera, a reč "corz.org" se ne nalazi u delu njegovog domena, onda PREPIŠITE ovaj zahtev.

Najvažniji konačni RewriteRule red upućuje mod_rewrite da prepiše sve podudarne zahteve (sve bez "corz.org" u svom refereru) tražeći gifs, jpegs ili pngs za alternativnu sliku.

Postoji mnogo načina na koje možete napisati ovo pravilo; pretražite Google za “hot-link zaštitu” i preuzmite celu hrpu toga. Jednostavno je najbolje. Umesto toga možete poslati malu poruku ili ih preusmeriti na neki loš skript, ili nešto. Moj je jednostavan corz.org logo za koji smatram da je prilično pametan. U stvari, ovih dana radim i nešto još pametnije-je..
 

gubitak "www"

Često me pitaju kako sprečavam “www” deo da se pojavljuje na mom sajtu, pa pretpostavljam da bi trebalo da dodam nešto i o tome. Ukratko, ako neko ukuca: http://www.corz.org/ u pretraživač (ili upotrebi www za bilo koji link na corz.org) to se preusmerava na čistu, običnu http://corz.org/ verziju. To je lako postići, dakle...

obratite pažnju na regularni izraz:
Options +FollowSymlinks
RewriteEngine on
RewriteCond %{http_host} ^www\.corz\.org [NC]
RewriteRule ^(.*)$ http://corz.org/$1 [R=301,NC]

Ne morate biti genije da biste videli šta se ovde dešava. Postoje i drugi načini za pisanje ovog pravila, ali opet, jednostavno je najbolje. Kao i većina primera ovde, navedeni primer je prekopiran direktno iz mog glavnog .htaccess fajla, tako da možete biti sigurni da savršeno funkcioniše. U stvari, nedavno sam ga ažurirao tako da mogu da delim pravila između mog razvojnog ogledala i živog sajta bez ikakvog .htaccess uređivanja.

Evo šta trenutno koristim:
Options +FollowSymlinks
RewriteEngine on
RewriteCond %{HTTP_HOST} ^www\.(.*) [NC]
RewriteRule ^(.*)$ http://%1/$1 [R=301,NC,L]
 

višestruki domeni u jednom korenu

Ako ste u nezavidnom položaju da vaši sajtovi žive na matičnom računaru koji ne podržava višestruke domene, možda ćete biti primorani da obrnete sopstveni uz pomoć .htaccess i mod_rewrite. Sve dok je fizička struktura direktorijuma dobro osmišljena, to se postiže dosta jednostavno.

Na primer, recimo da imamo dva domena koji ukazuju na jedinstveno udomljen koren; domain-one.com i domain-two.com. U korenu našeg web servera jednostavno kreiramo folder za svaki domen, možda jedan/i dva/ zatim u našem glavnom (korenu) .htaccess, prepišemo sve dolazeće zahteve, poput ovoga...

Svi zahtevi koji NISU već prepisani u ove foldere, transparentno prepisati...
#two domains served from one root..
RewriteCond %{HTTP_HOST} domain-one.com
RewriteCond %{REQUEST_URI} !^/one
RewriteRule ^(.*)$ one/$1 [L]

RewriteCond %{HTTP_HOST} domain-two.com
RewriteCond %{REQUEST_URI} !^two
RewriteRule ^(.*)$ two/$1 [L]

Svi zahtevi za matičnim računarom domain-jedan.com se prepisuju (ne R=preusmeravaju) u jedan/ direktorijum, pod uslovom da nisu već prepisani ovde (drugi RewriteCond). Ista priča i za domen-dva.com. Obratite pažnju na nekonzistentnost u RewriteCond iskazu; !^/dir-name i !^dir-name bi trebalo da rade dobro. Nepotrebno reći, ako dobijete grešku 500 na vašem serveru, to će biti dobro mesto za početak traženja!

Takođe obratite pažnju da, uz tako jednostavnu šemu imenovanja domena i foldera, lako možete da spojite ova dva skupa pravila. To se verovatno neće desiti u stvarnom svetu, zbog čega ih i držim odvojene; ipak, vredno pomena.

Ostala opšta podešavanja i php direktive takođe mogu da idu u ovaj koren .htaccess fajla, ali ako imate neka dalja prepisivanja koja želite da izvršite; skraćivanje URL-a, htm konverzija u php i drugo; verovatno je lakše i jasnije to uraditi unutar pod-direktorijuma .htaccess fajla.
 

аutomatsko prevođenje

Ako ne čitate engleski, ili ga vaši gosti ne čitaju, evo lepog načina da vam divan Google prevodilac obezbedi automatski onlajn prevod stranica vašeg sajta. Nešto poput ovoga...

оni jednostavno dodaju broj njihove zemlje na kraj linka, ili vi to uradite...
Options +FollowSymlinks
RewriteEngine on
RewriteRule ^(.*)-fr$ http://www.google.com/translate_c?hl=fr&sl=en&u=http://corz.org/$1 [R,NC]
RewriteRule ^(.*)-de$ http://www.google.com/translate_c?hl=de&sl=en&u=http://corz.org/$1 [R,NC]
RewriteRule ^(.*)-es$ http://www.google.com/translate_c?hl=es&sl=en&u=http://corz.org/$1 [R,NC]
RewriteRule ^(.*)-it$ http://www.google.com/translate_c?hl=it&sl=en&u=http://corz.org/$1 [R,NC]
RewriteRule ^(.*)-pt$ http://www.google.com/translate_c?hl=pt&sl=en&u=http://corz.org/$1 [R,NC]

Možete kreirati meni sa zastavama ili čim god želite i dodati pozivni broj za vašu zemlju na kraj linkova... <a href="pa ge.html-fr" id="... Želite da vidite ovu stranicu na francuskom?

Veoma je zgodno, i ja to koristim već nekoliko godina ovde u organizaciji za moje strane pratioce bloga, oboje, heh. Skoro niko ne zna za to, uglavnom zbog toga što nemam linkove. Jednog dana ću verovatno napraviti neke malene alatke sa zastavama i drugim. A možda i ne. Problem je što Google prevodilac prestaje da prevodi nakon određenog broja karaktera (što se izgleda povećava, dobro), iako bi ista ta pravila mogla lako da se primene i na druge prevodioce, a ako nađete nekog dobrog, nekog koji će prevesti zaista ogroman dokument, javite mi!

Ako ste želeli da budete zaista pametni, mogli ste da preduzmete i neku vrstu provere IP blokiranja i da automatski predstavite ispravnu verziju, ali to prevazilazi okvire ovog dokumenta. Obratite pažnju: to može biti nepoželjno za stranice na kojima su date tehničke komande (poput ove stranice) jer će se i komande prevesti. "RewriteEngine dessus" će vam skoro sigurno dati stranicu sa 500 greškom!

Još jedna stvar koju biste mogli da probate; radije nego individualne zastave zemalja; fr, de itd., upotrebite "u" zastavu za "Universal". Teoretski, Google će proveriti lokaciju klijenta i automatski prevesti na taj jezik. Jedan red u vašem .htaccess-u bi pokrio sve jezike i automatski pokrivao nove kako ih Google dodaje.

Dok sam tu, malo povezano; možete uraditi sličnu stvar sa strane pretraživača, napraviti "bookmarklet" (regularni obeleživač, osim što ovaj “radi nešto”) koristeći ovaj kod za lokaciju..
ista stvar, osim sa strane pretraživača...
javascript:void(location.href='http://translate.google.com/translate?u='+location.href)

...u kojoj ćete instinktivno naučiti da kliknete na najporstiji dah neprepoznatljivog teksta, pretpostavljam. Postavite je u polje sa alatkama, negde gde će biti vidljiv, to je moja iskrena preporuka.
 

httpd.conf

Zamaptite, ako postavite ova pravila u glavni serverski conf fajl (obično httpd.conf) radije nego u .htaccess fajl, moraćete da upotrebite ^/... ... umesto ^... ... na početku RewriteRule reda, drugim rečima, da dodate kosu crtu.
 

nasleđe...

Ako kreirate pravila u pod-folderima na vašem sajtu, morate ovo pročitati.

Setićete se kako se pravila u top folderima primenjuju i na sve foldere unutar tih foldera. To zovemo “nasleđe”. Normalno to tako funkcioniše. Ali ako počnete da kreirate nova pravila unutar pod-foldera, zapravo ćete izbrisati pravila koja se već primenjuju na taj folder zbog nasleđa, ili “decendencije”, ako više volite. Ne sva pravila, samo ona koja se primenjuju na taj pod-folder. Mala demonstracija...

koje preusmerava zahteve za fajlove koji se završavaju na .htm u njihov .php ekvivalent, baš kao u primeru na vrhu ove stranice. Sada, ako iz bilo kog razloga moram da dodam neka prepisana pravila u moj /osx/.htaccess fajl, .htm >> .php preusmeravanje neće više funkcionisati za /osx/pod-folder, moraću da ga ponovo ubacim, ali uz ključnu razliku..

ovo dobro radi, u širokom sajtu, u mom glavnom .htaccess fajlu
# main (top-level) .htaccess file..
# requests to file.htm goto file.php
Options +FollowSymlinks
RewriteEngine on
RewriteRule ^(.*)\.htm$ http://corz.org/$1.php [R=301,NC]

Evo mog ažuriranog /osx/.htaccess fajla, sa ubačenim .htm >> .php pravilom preusmeravanja...

аli moraću ponovo da ubacim i pravila za to da bi funkcionisali u ovom subćfolderu
# /osx/.htaccess file..
Options +FollowSymlinks
RewriteEngine on
RewriteRule some rule that I need here
RewriteRule some other rule I need here
RewriteRule ^(.*)\.htm$ http://corz.org/osx/$1.php [R=301,NC]

Uočite razliku u pravilu pod-foldera, istaknutu crvonom boјоm. Morate dodati trenutnu putanju novom pravilu. Sada ponovo radi, i svi osx/ pod-folderi će biti pokriveni novim pravilom. Ako to zapamtite, moći ćete iznova da prepisujete pravila svuda po sajtu.

Аko je moguće staviti sva rewrite pravila vašeg sajta u glavni .htaccess fajl, a verovatno jeste, uradite tako, poput ovoga..

to је dobra ideja staviti sva vaša pravila u vaš glavni .htaccess fajl...
# root /.htaccess file..
Options +FollowSymlinks
RewriteEngine on
# .htm >> .php is now be covered by our main rule, there's no need to repeat it.
# But if we do need some /osx/-specific rule, we can do something like this..
RewriteRule ^osx/(.*)\.foo$ /osx/$1.bar [R=301,NC]

Obratite pažnju, nema potpunog URL-a (sa domenom) u drugom primeru. Ne dozvolite da vas to omete; sa ili bez, on je funkcionalno identičan, na većini servera. Suštinski, probajte prvo bez potpunog URL-a, a ako to ne radi, ah, dodajte ga - možda na sledećem matičnom računaru!

Što se tiče poslednjeg, jednostavniji oblik je poželjniji, samo po svojoj izuzetnoj prenosivosti koju nudi - moj živi sajt i moj razvojni odraz dele potpuno iste .htaccess fajlove - visoko poželjna stvar.

Takođe, verovatno treba da se kaže i da, ako želite da onemogućite prepisivanje unutar određenog pod-foldera, u kome je omogućeno dalje uz stablo, samo uradite:

zgodno za avatar foldere, da se omogući hot-linking itd...
RewriteEngine off
 

kolačići

Na kraju, malo reči i o kolačićima. Veoma je lako podesiti kolačiće u .htaccess bez mod_rewrite..

stvorite kolačić pod nazivom “primer-kolačić” i podesite njegovu vrednost na “istinito”...
Header set Set-Cookie "example-cookie=true"

biće vam potrebno da biste ponovo mogli da pročitate informaciju o kolačiću i da “radite stvari” s njim. Na primer, da bismo proverili da li navedeni kolačić postoji i da li ima pravilan skup vrednosti, možemo uraditi...

proveriti isti taj kolačić + vrednost...
Options +FollowSymlinks
RewriteEngine on
RewriteCond %{HTTP_COOKIE} !example-cookie=true
RewriteRule .* /err/401.php

...što bi lako moglo da stvori osnovu za jednostavan sistem provere identiteta. Kao i sa bilo kojim drugim RewriteCond-om, može postati veoma zamršeno proveravati višestruke kolačiće, koristiti regexp i ostalo, ali to je dovoljno za početak. Verovatno ćete želeti da dodate još jedan RewriteCond da biste sprečili stvaranje petlje na 401. To ću ostaviti kao vežbu.


Dok sam kod toga, obratite pažnju, takođe možete podesiti kolačiće sa RewriteRule. Pogledajte ovo...

Podesite kolačić sa “Originalnim refererom” ovog posetioca, koristeći RewriteRule..
SetEnvIf Referer "^https?://(.*)/" myref=$1
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !corz.org [NC]
RewriteRule . - [cookie=original-referer:%{ENV:myref}:.%{HTTP_HOST}:1440:/]

Prvi red proverava vrednost zaglavlja “Referera” (koje obično šalje pretraživač - usput, pogrešno pisanje “referrera” smeta mnogima, ali je sada već čvrsto ukodiran u web).

Recimo da je referentni URI "http://corz.org/blog/", što se podudara )naravno da se podudara, svi refereri će se podudarati!), pa je deo između "https?://" i sledeće kose crte ("/") referentnog URI-a snimljen unutar zagrada () i zatim povratno referentan, backreferenced (upotrebom "$1", 1 = prvi snimljeni niz, u ovom slučaju "corz.org"), koja se vrednost arhivira u varijabli okruženja (Apache ih kreira gomile na svaki zahtev, vašu IP adresu, tpi pretraživača, vreme zahteva, daljinski port, učitavanja...) pod nazivom “mojeref”.

Drugim rečima: myref=corz.org

Možda ćete pitati: “Zašto jednostavno ne koristiti SetEnvIf Referer (.*) myref=$1 za kaptažu celog referentnog niza?”. Zbog toga što će snimljene tačke (":"), kada se prošire sa %{ENV:myref} construct, podeliti iskaz kolačića na pogrešnom mestu, jer će “:” biti graničnik. To podseća na programsku grešku, ali je predvidljivo.

Možete rizikovati i pokušati da snimite sve posle domena (koristeći SetEnvIf Referer "^https?://(.*)" myref=$1), ako nema dve tačke u URI, funkcionisaće dobro, snimajući upitne nizove i ostalo.

Zatim napravimo nekoliko RewriteCond uslova, prvi da spreči “prazne” referere (kada se ne šalje ni jedna referentna informacija), a drugi da spreči resetovanje kolačića sa imenom našeg sopstvenog domena*. A onda na posao..
* Аko se pitate: “Zašto ne upotrebiti %{HTTP_HOST} umestocorz.org, i napraviti univerzalni kod?”, koliko ja znam, nije moguće testirati jednu serversku varijablu u odnosu na drugu sa RewriteCond bez upotrebe Atomic Back References i ozbiljnog POSIX 1003.2+ Jiggery-Pokery. Generalno je najbolje upisati u kod ime domena. Kako god...

RewriteRule, je jednostavan tačka "." izraz, koji se opet podudara sa svakim pojedinim zahtevom, prenoseći zahtev pravo kroz njega (u bilo koji preostali .htaccess kod, upotrebom “-”) bez i najmanjeg menjanja URI-a, i dok to radi, podešava varijablu “originalni-referer” kolačića pretraživača na vrednost Apache varijable “mojref”, što je trenutno "corz.org", pristupajući toj varijabli upotrebom "%{ENV:}" construct..

Domen kolačića podešava se na "corz.org". Obratite pažnju, najbolje je koristiti prethodnu tačku u "www"-manje ili drugim pod-manje domenima).

Kolačić će isteći za otprilike 1440 minuta (24 časa). “Putanja” kolačića je podešena na “/” koja pokriva ceo sajt. Posao završen.

Konačno, pošto sam rekao SVE to, ipak bih mnogo radije koristio PHP sesije kada god je to moguće, a ako rizikujem s nečim permanentnijim, sa trajnim kolačićem, php (ili slično) je još uvek bolje mesto za kodiranje ovakvih stvari.

 

zaključak

Ukratko, mod_rewrite vam omogućava da šaljete pretraživače iz bilo koje lokacije u bilo koju lokaciju. Možete kreirati pravila ne samo na osnovu zahtevanog URL-a, već i na takvim stvarima kao što je IP adresa, agent pretraživača (slanje starih pretraživača na različite stranice, na primer) i čak vreme dana; mogućnosti su praktično neograničene.

Unutrašnjost i spoljašnjost mod_rewrite sintakse su teme za mnogo duži dokument od ovog, a ako vam se dopada eksperimentisanje sa naprednijim pravilima prepisivanja, podstičem vas da pogledate Apache dokumentaciju.

Аko imate Apache instaliran na vašem sistemu.. verovatno postoji i kopija Apache priručnika, upravo ovde, i odličan mod_rewriting vodič, upravo ovde. Pogledajte Napomene za URL mehanizam prepisivanja za sočne sintaksičke bitove. Tu sam našao i simpatičan citat za vrh stranice.
 
;o) Cor
 
 

saveti za otkrivanje problema...

Fatalno preusmeravanje

Ako počnete da se zanimate sa 301 preusmeravanje [R=301], tzv. " Trajno preusmeravanje”, a vaše pravilo ne radi, možete sebi zadati ozbiljne glavobolje...

Kada se jednom pretraživač trajno preusmeri na pogrešnu adresu, ako zatim krenete da izmenite problematično pravilo, vaš pretraživač će i dalje biti preusmeren na staru adresu (jer to je tako sa pretraživačima) i čak možete krenuti da to popravite, i zatim ga ponovo prekinete, a da to ni ne znate. Izmene u 301 preusmeravanju mogu uzeti puno vremena pre nego što se pojave u vašem pretraživaču.

Rešenje: restartujte pretraživač ili upotrebite drugi.

Bolje rešenje: Upotrebite [R] umesto [R=301] dok testirate. Kada budete 100% sigurni da pravilo radi tačno ono što očekujete, tada ga prebacite na [R=301] za vaš živi sajt.
 

prepisivanje evidentiranja...

Kada stvari ne funkcionišu, možda ćete poželeti da omogućite prepisivanje evidentiranja. Pretpostaviću da testirate ove mod_rewrite direktive na vašem razvojnom odrazu, ili sličnom podešavanju, i da možete pristupiti glavnom httpd.conf fajlu. Ako ne možete, zašto ne možete? Testiranje mod_rewrite pravila na vašem živom domenu nije baš idealno, jel da? U svakom slučaju, stavite to negde pri dnu vašeg http.conf..

Očekivanje velikih fajlova za evidentiranje..
#
# ONLY FOR TESTING REWRITE RULES!!!!!
#
RewriteLog "/tmp/rewrite.log"
#RewriteLogLevel 9
RewriteLogLevel 5

Podesite lokaciju fajla i stepen evidentiranja da odgovara vašem sopstvenom orkuženju. Ako vaše pravilo uzrokuje zapetljavanje Apacha, učitajte stranicu, odmah pritisnite “STOP” taster vašeg pretraživača, a zatim restartujte Apache. Sve u par sekundi. Vaša prepisana prijava će biti puna informacija o dijagnozi, a vaš server će nastaviti po običaju.

Podešavanje vrednosti 1 ne donosi vam skoro nikakve informacije, podešavanje stepena evidentiranja na 9 donosi vam GIGABAJTOVE! Stoga morate zapamtiti da prokomentarišete ta pravila i da restartujete Apache kada završite, jer ne samo da će prepisivanje evidentiranja stvoriti fajlove koji zauzimaju prostor, već će ozbiljno ugroziti izvođenje vašeg web servera.

RewriteLogLevel 5 je veoma koristan, ali 2 je verovatno dovoljno informacija za većinu problema.

 

debug-report.php
php skript koji će uveliko olakšati život vašeg mod_rewrite modula

Kada se stvari ne odvijaju onako kako ste očekivali, prepisivanje evidentiranja je dobra opcija, ali na serveru koji nije matični verovatno nećete imati tu opciju ako ne pristupite httpd.conf. Na sreću, ono što je obično potrebno je samo brzo iščitavanje svih trenutnih varijabli servera, $_GET niz itd.; tako da tačno možete videti šta se desilo sa zahtevom.

Za drugu svrhu, davno sam kreirao debug.php, a kasnije, kada sam otkrio koliko su sve te informacije korisne za pronalaženje pogrešnih prepisa, kreirao sam “izveštaj” verziju koja, umesto da ostvari izlaz u fajl, vraća informacije ponovo u pretraživač, kao $_POST, $_SESSION i $_SERVER nizovi, specijalne varijable, kao __FILE__ i još mnogo drugog

Upotreba je jednostavna; činite je vašom ciljnom stranicom, pa u pravilu kao što je ovo...

RewriteRule ^(.*)\.html$ /catch-all.php?var=$1

Kopija debug-report.php će se privremeno preimenovati u catch-all.php u korenu vašeg servera, a http://testdomain.org/foobar.html u adresno polje vašeg pretraživača i, uz zer mojo debug-report.php uskočiće u vaš pretraživač uz učitavanje tačno onih informacija koje su vam potrebne da biste otkrili sve to. Kada radim sa mod_rewrite, debug-report.php mi štedi vreme, mnogo. Mnogo je brže od omogućivanja prepisivanja evidentiranja. A i besplatno je..

 
 
Published (Last edited): 23-01-2013 , source: http://corz.org/serv/tricks/htaccess2.php