Telenet Cloud Online Help

Gebruik van ‘vriendelijke’ URL’s op mijn Linux hosting

De mod_rewrite module van de Apache (Linux) webserver geeft u de mogelijkheid om transparant bezoekers door te sturen naar verschillende URL’s, zonder dat dit bezoeker opvalt. Dit geeft toegang tot verschillende mogelijkheden, van het simpel doorverwijzen van oude URL’s naar hun nieuwe locatie, tot het opkuisen van de ’lelijke’ URL’s die door Content Management System (CMS) applicaties gemaakt kunnen worden – wat u URL’s oplevert die vriendelijk zijn voor zowel bezoekers als zoekrobotten (bv. Google).

 

Inleiding

 

Leesbare URL’s zijn aangenaam. Een goed ontwikkelde website zal een logische layout hebben, met slimme map en bestandsnamen en zo weinig mogelijk zichtbare implementatie details. Bij de best ontwikkelde websites, kan een bezoeker met een hoge graad van correctheid bestandsnamen raden.

 

Er zijn echter situaties waar zelfs het best uitgebouwde design niet kan tegenhouden dat uw URL’s haast onmogelijk zijn om te gebruiken of te onthouden. U gebruikt bijvoorbeeld een CMS die URL’s aanbied zoals hieronder:

 

http://www.voorbeeld.be/winkel.asp?type=hoeden&prodID=53

 

Dit is een voorbeeld van een slechte URL, en wel omwille van de volgende redenen:

 

· Het toont de onderliggende technologie van de website (in dit geval ASP). Dit kan potentiële hackers een tip geven voor welke methodes zij kunnen gebruiken om de query string als toegangspoort voor een aanval te gebruiken. Dergelijke informatie kan best niet tentoongesteld worden.

 

Ook al bent u niet echt begaan met de veiligheid van uw website, de technologie die u gebruikt is voor de bezoeker niet relevant – en kan in het slechtste geval zelfs tot verwarring leiden – dus dit kunt u het best voor hen verborgen houden.

 

Ook indien u in de toekomst zou beslissen om de taal waarin uw website is geschreven aan te passen (naar PHP bijvoorbeeld), dan zouden al uw URL’s onbruikbaar worden. Dit kan een zeer groot probleem zijn, zoals iedereen die een volledige herschrijving van een website heeft moeten uitvoeren zal kunnen beamen.

 

· De URL is bezaaid met leestekens, zoals het vraagteken en de ampersand (&). Vooral die & tekens kunnen problematisch zijn, omdat indien andere webmasters naar een dergelijke URL willen linken, dit problemen kan opleveren voor hun eigen code. Zij moeten dan manueel alle & tekens aanpassen naar ’&’, wat regelmatig over hoofd kan gezien worden.

· Sommige zoekrobotten zullen pagina’s die dynamisch gegenereerd lijken niet indexeren. Bij het eerste zicht van een vraagteken in de URL stoppen ze de indexatie van (dat gedeelte) van uw website.

Gelukkig genoeg kunnen we echter mod_rewrite gebruiken om deze URL aan te passen naar iets dat veel bruikbaarder is. Als we verder gaan op bovenstaand voorbeeld, zou het bijvoorbeeld als volgt kunnen worden:

http://www.voorbeeld.be/winkel/hoeden/53/

 

Wat al veel beter oogt. Deze URL is logischer, leesbaarder en makkelijker te onthouden en zal door alle zoekrobotten verwerkt worden. De ’valse’ directories zijn kort en beschrijven hun doel. Ook belangrijk, het ziet er permanent uit.

Om mod_rewrite te gebruiken, zult u de tekst, waarvan u wenst dat die omgevormd wordt, moeten melden aan de server, alsook de echte URL’s waar deze opgekuiste URL’s in feite terecht komen. Dit kan een rechtstreekse link zijn, die dan één bepaalde pagina zal behandelen, of u kunt ’regular expressions’ gebruiken, die hele reeksen bestanden kunnen opvangen.

 

Basis rewriting

 

Maak lokaal een bestand aan en noem dit “.htaccess”, bijvoorbeeld via “kladblok”. Elke .htaccess bestand zal beginnen met onderstaande regel:

RewriteEngine on

Plaats dit bestand in de map wwwroot van uw hosting, zo zal het voor de gehele website tellen. U hebt bovenstaande regel slechts eenmaal per bestand nodig.

 

Basis redirects

 

We zullen beginnen met een simpele, rechtstreekse redirect; als u bijvoorbeeld een bestand op een andere locatie hebt geplaatst, en wenst dat alle bezoekers van de oude URL’s automatisch naar de nieuwe URL’s worden doorverwezen.

RewritEngine on

RewriteRule ^oud.html$ nieuw.html

 

Alhoewel dit het meest eenvoudige voorbeeld is, zal het alsnog vrij verwarrend overkomen. De structuur van de ’oude’ URL is vooral een struikelblok. Er worden hier 3 speciale tekens gebruikt:

 

· De circumflex, ^, geeft de start van een URL aan, uitgaande van de map waarin de .htaccess geplaatst is. Als u dit in de wwwroot van de hosting van www.voorbeeld.be zou plaatsen, zou de ^ dus www.voorbeeld.be betekenen, als u dit in de submap /test/ zou plaatsen, zou dit www.voorbeeld.be/test/ betekenen. Bijna alle regels zullen met een ^ beginnen.

· Het dollarteken, $, betekent het einde van de tekst die aangepast moet worden (de string die gematched moet worden). U dient deze toe te voegen op het einde van de regel om tegen te gaan dat enkel het eerste gedeelte van een lange zoekopdracht verwerkt wordt.

· Het stopteken of punt, ., voor het begin van het bestandstype (in dit voorbeeld, .html) is een speciaal teken in regular expressions, en zou dus ongewenst behandeld worden, als we het niet zouden ’escapen’ door gebruik te maken van de backslash (), die tegen mod_rewrite/Apache zegt dat het als normaal teken behandeld moet worden.

Wat zal deze regel nu concreet doen? Het automatisch doorsturen van bezoekers van www.voorbeeld.be/oud.html naar www.voorbeeld.be/nieuw.html. De bezoeker merkt hier niets van en ook op de snelheid van de website heeft dit geen invloed.

 

Nieuwe requests dwingen

 

Soms wenst u dat de bezoeker net wél merkt dat hij naar een andere pagina is doorgestuurd, en dit kan door een nieuwe HTTP request voor de nieuwe pagina af te dwingen. Hierdoor zal de browser de nieuwe pagina laden, net zoals de bezoeker hier rechstreeks op beland zou zijn, en het adres in de browser zal ook aangepast worden naar de URL van de nieuwe pagina. Het enige dat hiervoor dient te gebeuren is het toevoegen van de markering [R] aan het einde van de regel, zoals hier:

 

RewriteRule ^oud.html$ nieuw.html [R]

 

Gebruik van Regular Expressions

 

De kracht en flexibiliteit van mod_rewrite komt ten koste van enige complexiteit. Indien dit uw eerste kennismaking met Regular Expressions zal zijn, is het mogelijk dat u hier een steile leercurve tegemoet gaat, maar de mogelijkheiden die hierdoor geboden worden, maken het meer dan de moeite waard. Wij zullen hier enkele voorbeelden aanhalen om u alvast op weg te helpen door de basis.

 

Door gebruik van Regular Expressions kunt u met één of enkele regels, een hele resem URL’s aanpakken. Als we even onderstaand voorbeeld aanhalen:

 

RewriteRule ^producten/([0-9][0-9])/$ /productinfo.php?prodID=$1

 

Dit zal gelden voor elke URL die begint met http://www.voorbeeld.be/producten/, gevolgd door twee willekeurige cijfers, gevolgd door een schuine streep (/). Dit zou bijvoorbeeld URL’s zoals www.voorbeeld.be/producten/12/ en /producten/99/ opvangen en doorsturen naar de PHP pagina zoals in het tweede gedeelte van de regel.

 

De gedeeltes tussen rechte haakjes worden ’ranges’ genoemd. In dit geval zal het alles in de ’range’ 0-9 toelaten, wat overeenkomt met elk cijfer. Andere voorbeelden van ranges zouden bv. zijn [A-Z], waarmee elk hoofdletter wordt bedoeld, [a-z] elk kleine letter; en [A-Za-z] wat zowel hoofd- als kleine letters zou omvatten.

 

We hebben het ’regular expression’ gedeelte van deze regel tussen haakjes geplaatst, omdat we de waarde die hierin gegeneerd wordt, willen kunnen opslaan voor later gebruik. In dit geval sturen we deze waarde door naar een PHP pagina als argument. Eens we deze waarde tussen haakjes hebben, kunnen we het gebruiken door wat een ’back-reference’ wordt genoemd toe te passen. Elk van de delen die tussen haakjes worden geplaatst, hebben een indexering, oplopend van 1. Dus de eerste ’back-reference’ zal $1 zijn, de derde is $3 enz

 

Eens de redirect daardoor gedaan is, zal de pagina die in de browser geladen wordt, overeenkomen met zoiets als productinfo.php?prodID=12. Vanzelfsprekend wordt dit voor de bezoeker verborgen, zodat we een mooie URL kunnen presenteren.

 

Meerdere redirects

 

Indien uw bezoeker een URL intikt zoals ’products/12’, zal de bovenstaande regel niet werken aangezien er geen ’/’ op het einde is. Om dit te omzeilen, kunnen we een redirect doen waarbij het ontbreken van de / ook wordt aangepakt.

 

RewriteRule ^producten/([0-9][0-9])$ /producten/$1/ [R]

Meerdere redirects kunnen in één .htaccess bestand sequentieel toegepast worden. De regel wordt toegevoegd boven de vorige:

 

RewriteRule ^producten/([0-9][0-9])$ /producten/$1/ [R]

RewriteRule ^producten/([0-9][0-9])/$ /productinfo.php?prodID=$1

 

Zo bereiken we dat als de user ’producten/12’ intikt, de eerste regel van kracht wordt, die de URL herschrijft zodat die wel wordt afgesloten met een schuine streep. Dit wordt dan omgevormd naar een nieuwe request voor ’/producten/12/’, zodat de gebruiker kan zien dat we werken met schuine strepen op het einde van de URL. Na de redirect kan de tweede regel in werking treden, waardoor transparant productinfo.php?prodID=12 wordt opgeroepen.

 

Match Modifiers

 

We kunnen onze regular expression matches uitbreiden door er enkele ’modifier’ karakters aan toe te voegen, zodat de URL’s die aangepast worden quasi oneindig uitgebreid kunnen worden. In de voorbeelden die reeds aangehaald zijn geweest, hebben we ons steeds beperkt tot slechts twee cijfers. Dit is natuurlijk niet de meest flexibele oplossing. Indien de winkel zou uitbreiden en meer dan 99 producten zou aanbieden, zouden de URL’s niet langer aangepast worden.

 

Dus kunnen we in plaats van een bepaalde reeks cijfers te definiëren, wat meer groeiruimte incalculeren door een onbeperkt aantal cijfers of tekens te matchen:

 

RewriteRule ^producten/([0-9]+)$ /producten/$1/ [R]

 

Let goed op het plus teken (+) dat nu in de regel aanwezig is. Deze modifier past al het voorgaande aan, door te zeggen ’één of meer van de voorgaande karakters’. In dit geval zal de regel alle URL’s die beginnen met ’producten/’ en eindigen met minstens één cijfer opvangen. Dit zal dus zowel producten/1 als producten/1000 opvangen.

Andere “match modifiers” die gebruikt kunnen worden zijn de asterisk ,*, wat overeenkomt met ’0 of meer van de voorgaande tekens of range’ en het vraagteken, ?, dat overeenkomt met ’nul of slechts één van de voorgaande karakters of range’

Toevoegen van “gokbare” URL’s

 

Door gebruik van deze eenvoudige commando’s kunt u ’”shortcut URL’s” aanmaken, waarvan u denkt dat bezoekers deze zouden gebruiken om pagina’s te bereiken waarvan ze het bestaan op uw site kennen. Voortgaand op het voorbeeld hierboven, zou het kunnen dat mensen die uw webshop bezoeken onmiddellijk www.voorbeeld.be/hoeden/ zouden kunnen tikken. Deze kunnen opgevangen worden, en middels het adres in de adresbalk proberen de bezoeker te tonen wat wel de juiste URL zou zijn:

RewriteRule ^hoeden(/)?$ /producten/hoeden/ [R]

De eenvoudige regular expression die gebruikt wordt in deze regel, laat toe dat de hoeden URL geredirect wordt, met of zonder / op het einde, aangezien we het ? gebruiken die “0 of 1 van de voorgaande tekens” bepaalt – met andere woorden zowel www.voorbeeld.be/hoeden als www.voorbeeld.be/hoeden/ zullen beiden door deze regel opgevangen worden.

 

Deze aanpak zorgt voor minder 404 errors voor uw bezoekers en een site die beter gestructureerd weergegeven kan worden.

0 (0)
Artikel waardering ()
Geef een waardering aan dit artikel
Bijlagen
Er zijn geen bijlagen voor dit artikel.
Gerelateerde artikels
Hoe installeer ik Joomla op Linux Hosting?
3714 keer bekeken sedert Fri, Sep 4, 2009
Wijzigingen Shared linux hosting omgeving php 5.4 (apache21)
1331 keer bekeken sedert Tue, Dec 17, 2013
Aanmaken van subdomeinen op Linux shared hosting
1492 keer bekeken sedert Tue, Jul 24, 2012
Directory beveiligen met een gebruikersnaam en wachtwoord op Linux
3842 keer bekeken sedert Thu, Feb 26, 2009
Moet ik een Linux computer hebben om Linux hosting te bestellen?
2763 keer bekeken sedert Mon, Jul 9, 2012
Kan ik de maximale down- upload size verhogen op Linux hosting?
1474 keer bekeken sedert Wed, Aug 8, 2012
Is het uitvoeren van exec(), system()-PHP functies toegelaten op shared hosting?
1540 keer bekeken sedert Tue, Aug 7, 2012
PDF bestanden aanmaken via PHP
1471 keer bekeken sedert Tue, Aug 7, 2012
Kan er gebruik gemaakt worden van FTPS op linux shared hosting?
1228 keer bekeken sedert Mon, Sep 3, 2012