FollowSymLinks

Ik snap wat je bedoelt. Ik heb vroeger wel eens geëxperimenteerd met FallbackResource en kan me daar geen problemen mee herinneren. De truc met het errordoc is nieuw, maar als het werkt wel een mooie.

De regels die Thomas geeft (let vooral op de directory controle in RewriteCond) leveren hetzelfde op als een fallback. Persoonlijk zou ik directories niet uitfilteren, maar dat is een kwestie van smaak. Aan ErrorDocument zit een simpele eis vast dat je de status correct moet instellen, en dit niet via POST werkt.

Uiteindelijk stel ik altijd als eis dat anderen ook met de code moeten kunnen werken. Rewrite rules worden door iedereen begrepen, praktisch niemand kent de alternatieven. Als je doel is "ik wil FollowSymlinks niet aan hebben", maar tegelijk heb je geen andere gebruikers op je server, waar maak je je dan eigenlijk druk om? Zoals gezegd, de "risks" die bij FollowSymlinks worden genoemd gelden wanneer je geen controle hebt over wat je gebruikers uitspoken, i.e. shared hosting. Er zijn geen verdere risico's, want ik kan me niet voostellen dat je zoiets stoms doet als ln -s /etc.

>> Aan ErrorDocument zit een simpele eis vast dat je de status correct moet instellen, en dit niet via POST werkt.

Wat bedoel je hier mee ... ik volg je even niet (het is al laat).

De status van het request zal standaard 404 zijn wanneer je een ErrorDocument 404 gebruikt. Dit moet je dan omzeilen door in je headers hardhandig aan te geven dat de status 200 is, of welke status je ook wilt geven. Ook werkt POST niet, omdat je ErrorDocument door een interne nieuwe request wordt opgevraagd waar geen POST data in zit.

De truc met het errordoc is nieuw, maar als het werkt wel een mooie.

Nou nee, het is min of meer een oneigenlijk gebruik van een voorziening. En ook eentje met haken en ogen zoals @Ben hierboven en ik al eerder aangaven. Maar als je niets anders hebt (je gebruikt geen Apache) dan zou je dit kunnen overwegen. Aan de andere kant, waarom had je dan gekozen voor een technische oplossing zonder Apache wanneer dit toch verdomd handig was geweest?

Wat @Ben eerder zei over nette URL's in zoekpagina's:

Net als zoekpagina's trouwens. Ik kan altijd lachen om de bochten waarin men zich wringt om zoekpagina's van nette urls te voorzien, terwijl het helemaal geen nut heeft.

Uit optiek van zoekmachines is dit inderdaad niet erg nuttig maar uit oogpunt van werk kan het aanhouden van één schrijfwijze van URLs toch makkelijker zijn (en tevens heb je hiermee uniformiteit). En mogelijk heb je ook grijze gebieden. Denk bijvoorbeeld aan doorzoekbare/sorteerbare/filterbare portfolio-pagina's.

Deze luxe (enkelvoudige schrijfwijze) heb je niet bij een oplossing middels de "404 redirects" - het POSTen van data zal hoe dan ook via een ander pad moeten verlopen (pun intended), bijvoorbeeld via een andere schrijfwijze van een URL die rechtstreeks aan index.php refereert. Bij deze oplossing blijf je dus een soort duaal stelsel (wel en niet zoekmachinevriendelijke URLs) in stand houden. Dit heeft ook zekere voordelen maar het is wederom extra werk.

Ik heb het idee dat jij (Ozzie) de laatste tijd nogal zoekende bent op allerlei uiteenlopende gebieden waarbij je (correct me if I'm wrong) een soort "beste antwoord" zoekt. Het feit dat er meestal meerdere oplossingen bestaan (die ook min of meer hun bestaansrecht bewijzen? als er geen behoefte zou zijn aan verschillende insteken zouden deze op den duur verdwijnen?) wil mogelijk zeggen dat er geen "beste oplossing" is. Er zijn enkel keuzes die je kunt maken en implicaties die deze keuzes hebben. Ik denk dat het zinniger is als je eerst een soort van pakket van eisen hebt "dit is wat ik wil dat iets moet kunnen" en dat je vervolgens kijkt wat er beschikbaar is en wat je hier (niet) mee kunt doen. Indien je de implicaties goed overziet kun je met enige zekerheid een juiste keuze maken. Dat is soms het best haalbare. Of je probeert meerdere alternatieven uit en kijkt wat voor jou het beste werkt.

>> Ook werkt POST niet, omdat je ErrorDocument door een interne nieuwe request wordt opgevraagd waar geen POST data in zit.

Maar dit is neem ik aan alleen het geval wanneer je post naar een 403 pagina zou leiden toch? Als je post naar een normale pagina is dit toch niet van toepassing?

>> Deze luxe (enkelvoudige schrijfwijze) heb je niet bij een oplossing middels de "404 redirects" - het POSTen van data zal hoe dan ook via een ander pad moeten verlopen (pun intended)

Ik snap dus nog steeds even niet wat dat errordocument te maken heeft met het posten :-s

Anyhow ... ik ben het wel er mee eens dat het een oneigenlijk gebruik is van een errordocument, dus misschien is de 'normale' oplossing dan toch wel beter.

In de herhaling: een ErrorDocument wordt niet direct opgevraagd, dit loopt via een subrequest. Dus Apache vult een compleet nieuwe request in en doet daarmee een verzoek om het document. In dit nieuwe verzoek zit geen POST data, omdat foutmeldingen niet geacht worden data te verwerken.

Dat snap ik ... maar wat ik bedoel is ... op het moment dat een errordoc wordt aangeroepen is er blijkbaar een verboden pagina aangeroepen. Normaliter komt een formulier niet op een verboden pagina terecht en zal dit probleem zich dus niet voordoen lijkt mij.

(Dit even afgezien van of het wel of niet een chique manier is.)

Je POST naar virtuele pagina X.
X bestaat niet, je wordt geredirect naar 404 pagina Y.
Op pagina Y is $_POST leeg.

Met navigatie via de error document wordt je altijd geredirect... Of in ieder geval dit gedraagt zich als een redirect, wat er ook onder water moge gebeuren.

Ah zo bedoel je ... echter normaliter word je niet naar een 404 pagina / virtuele pagina geleid, maar gewoon rechtstreeks naar index.php

Het redirecten zou alleen plaatsvinden als de url overeenkomt met een BESTAANDE map. Dat zou een 403 error opleveren die je naar index.php kunt doorsturen. Echter, alle normale pagina-aanroepen vinden dus plaats via de fallback en NIET via het errordocument. De situatie zoals je die schetst zal dus in werkelijkheid niet plaatsvinden.