Een typische URL van een dynamisch gegenereerde website ziet er bijvoorbeeld zo uit:
http://www.website.com/index.xxx?id=a12e5d4a-45ad6-f89a&ln=en
Die index.xxx is dan bijvoorbeeld index.aspx (ASP.NET), of index.cfm (ColdFusion), of index.php (PHP), en de URL hierboven zou dan bijvoorbeeld willen zeggen dat de inhoud van een bepaalde pagina die in de database de code a12e5d4a-45ad6-f89a heeft, in het Engels moet getoond worden (ln=en).
Probleem is dat dat er niet uitziet. En dat het weinig betekenis heeft ook, en niet erg behulpzaam is voor een gebruiker.
Pak daarentegen een URL als
http://www.website.com/diensten/consultancy/internet
…voor een gebruiker ziet dat er al heel wat beter uit (voor Google trouwens ook, maar da’s nog een ander verhaal). Een bezoeker van de website kan aan de URL meteen afleiden dat er ook een
http://www.website.com/diensten/consultancy
en een
http://www.website.com/diensten
zou moeten bestaan, en dat daar relevante inhoud zou kunnen staan.
Om van het eerste naar het tweede te geraken, heb ik over de jaren heen een hoop Truken Van De Foor gebruikt, maar ze vallen in twee uit elkaar: query_string parsing en 404-dinges.
De allereerste was dat het door een bug (?) in Internet Information Server mogelijk was om een URL als deze te gebruiken:
http://www.website.com/index.xxx/pg/diensten/ln/en
Nog altijd een indexpagina, niet gevolgd door ?param=waarde¶m2=waarde2 maar wel door /param/waarde/param2/waarde2, waarbij die hele zooi in één parameter doorgestuurd werd. Met andere woorden: in één grote query_string, die dan met een klein beetje parsing in parameter/waarde-paren uitgesplitst kon worden.
Tweede methode: de 404-pagina van een website naar een switchboard-pagina sturen, waar de URL kan geparsed wordne, en waar de juiste inhoud kan doorgestuurd worden. Voordeel is dat alle URLs mogelijk zijn, en dat er nergens een beperking is op om het even wat. We hebben die techniek gebruikt op De Kust, waar geen enkele statische pagina is, maar waar de hele site werkt via een centrale 404.
…en nu ik voor het eerst in mijn leven Apache van dichtbij zie in ‘t echt, zie ik dat mod_rewrite zowat dezelfde functie heeft, en dat ik er eens zeer aandachtig naar ga moeten kijken.
… en dan heb je Cocoon nog niet bekeken, daar begint alles bij de definitie van de URL space. 😉
Cool, die 404 truuk is eigenlijk wel zeer zeer goed bedacht (zeer vieze truuk ook wel). Wordt de gebruiker dan geforward naar die 404 en dan door de 404 naar de juiste pagina na parsing van de referer zonder dat hij dat ziet? Of kan er bij een trage verbinding een keer die 404 te voorschijn komen (die dan blanco getoond wordt neem ik aan)? Probleem is dat die parsing wel gelimiteerd moet worden zodat de gebruiker, door constructie van een speciale url, geen doorgang heeft naar de beveiligde of verboden directories (/passwd of zo). Wat ik dan nog niet snap is hoe de echte eind-url (die dus met onleesbare parameters) verborgen wordt voor de gebruiker. Toch geen frame he?
On a side note: Microsoft site is gehacked (geweest), IIS6 zal binnenkort een paar patches krijgen denk ik 🙂
Het werkt als volgt:
stel IIS (of apache, of wat dan ook) zó in, dat de 404-pagina verwijst naar een dynamisch pagina, bvb. index.php
geef een “foute” URL in, bvb. /kleuren/groen/
de URL die in de browser te zien is, is niet de URL van de 404-pagina, maar blijft gewoon de “foute” URL — kijk maar na als je bvb. http://www.google.com/kleuren/groen/ ingeeft)
here’s the trick: die “/kleuren/groen/” kun je uit de CGI scope halen; het komt er dan op aan om index.php (die de 404-pagina “maakt”) op te vullen met de juiste inhoud
één mogelijkheid om dat te doen, is in een database te zoeken naar inhoud die overeenkomt met “/kleuren/groen/”: misschien is dat een unieke identifier of zo, of misschien is er een hiërarchische boom gedefinieerd en hebben “/kleuren/” en “/groen/” elke betekenis. Of misschien zoek je op de server naar een XML-bestand met de naam “kleuren-groen.xml”, of is er een andere manier om de inhoud te vinden
maar die inhoud wordt dus in de index.php geserveerd, dynamisch, met de juiste content-types en de nodige headers (dat laatste om te vermijden dat er een échte 404 naar de browser gestuurd wordt)
dus voor alle duidelijkheid: er is géén redirect, er is geen sprake van frames of zo 🙂
Voor De Kust worden de “/kleuren/groen/”-gegevens gebruikt om in een vooraf opgebouwde boomstructuur te gaan zoeken welke stukken content bij elkaar geplakt moeten worden samen met navigatie en andere dynamische dingen zoals weerbericht, crosslinks, etc.
O ja, en voor extra crispy viezigheid: schrijf ook meteen valse weblogs, anders staan de logs vol met 404;/kleuren/groen, index.php en dergelijke.
Door “valse” logs te schrijven met hetzelfde formaat als “echte” logs kun je met standaard tools (webtrends of livestats en zo) een dynamische website veel betekenisvoller analyseren, door er bijvoorbeeld een directorystructuur in te steken. Anders zou je bijvoorbeeld 100% hits op index.php hebben (of .cfm, .aspx, …); nu heb je hits op /kleuren, /kleuren/groen, /kleuren/rood, …
Cocoon is perfect voor zoiets. In .NET kan dit makkelijk op twee manieren. Als je geen .aspx in je URL wil, of misschien URLs met een extensie als .michel wil, ga je in IIS alle requests moeten mappen naar de aspnet_isapi.dll. Je zorgt er dan zelf voor dat dingen als .jpg, .js etc goed worden opgevangen.
Vind je echter de .aspx niet zo erg, kan je makkelijk met custom Httpandlers werken. Je kan vb Regular Expressions schrijven die bepaalde URL’s naar bepaalde HttpHanlders sturen, en zo een bepaald type pagina terug geven.
http://www.werkenantwerpen.be werkt zo. Alle URLs die je tegenkomt in die site zijn gegenereerde paginas. Er staat geen enkele .aspx file fysiek op de harde schijf. User friendly URLs rule.
Yep, die had ik er nog vantussen gelaten, andere extensies en die naar de juiste ISAPI sturen (in mijn geval in de tijd ColdFusion).
Ik heb een half oog op Cocoon gesmeten, en misschien is het de documentatie of zo, maar ‘t ziet er redelijk ingewikkeld uit allemaal.
Door Cocoon moet je je even doorworstelen.
Ik heb het als huis, -tuin en keuken gebruiker een beetje leren kennen.
Beginnend bij de voorbeeldjes en gesteund door een heel actieve usercommunity ben ik toch redelijk ver gekomen.
Gnnn… nog dingen te leren. ‘t Zal voor, euh, dan eens zijn.
Heb je trouwens al gespeeld met OpenCMS ?
Als het gaat over navigatiestructuren en kant en klare html-pagina’s of andere pagina’s te publiceren vind ik dat OpenCMS wel kan tellen.
Ik heb eignelijk met nog niet veel gespeeld. Ik ken mensen die zweren bij Typo3, en al ziet dat er op het eerste gezicht allemaal redelijk overkill uit voor de meeste zaken, ga ik mij daar eerst wat meer in moeten verdiepen dan ik al gedaan heb, kwestie van te kunnen samenwerken met die mensen.
Voor de rest ben ik het inderdaad beu om het wiel telkens opnieuw uit te vinden, en ga ik eens dringend op zoek gaan naar een goed CMS, als het even kan gratis en open source.