Omdat ik bezig ben met een redesign van mijn website, die online draait op een apache webserver, heb ik hem thuis gemirrorred zodat ik kan testen. Als een echte windowshippie draai ik natuurlijk zelf IIS 
Ik maak echter gebruik van apache's MultiViews uitbreiding, en aangezien ik de site thuis precies hetzelfde wil hebben, en ik geen multiviews ISAPI filter heb kunnen vinden, besloot ik maar om er zelf een te schrijven.
Anyway, dat is allemaal niet interessant, het gaat me nu om het filter zelf (dus opmerkingen als "waarom installeer je niet gewoon apache" mag je achterwege laten
Als iemand een 3rd party multiviews ISAPI filter weet stel ik dat echter zeer op prijs)
Mijn filter is nu zover dat hij een url als /bla/test.php/1/2/3 omzet naar /bla/test.php. Echter, die /1/2/3 gaat verloren, en ik wil natuurlijk wel dat dat opvraagbaar is vanuit de CGI applicatie (PHP in dit geval). Apache zet deze extra info in PATH_INFO, alleen ik krijg het in mijn filter niet voor elkaar om die variabele te zetten.
Allereerst kun je dergelijke variabelen alleen maar opvragen vanuit je filter. Uit de MSDN maak ik op dat, als je de waarde van PATH_INFO opvraagt, er een URL_MAP notification door de filters wordt gestuurd, die de url omzet naar een fysiek pad. De documentatie hierover is echter wat summier, maar ik vermoed dat ik hier iets mee moet doen, aangezien IIS deze notification gebruikt om de PATH_INFO uit te vogelen (alsmede het daadwerkelijke bestand dat aangeroepen moet worden).
Heeft iemand enig idee hoe ik de PATH_INFO kan zetten voordat PHP aangeroepen wordt, zij het via die URL_MAP notification, of gewoon op een andere manier?
Dingen als SetEnvironmentVariable () werken niet, omdat IIS de var aanpast vlak voordat PHP invoked wordt. Bovendien denk ik niet dat IIS de variabelen 1 voor 1 gaat zetten in de huidige process, maar gewoon een array stuurt naar het childprocess (via CreateProcess ())
Momenteel neig ik naar een ander alternatief, namelijk een CGI wrapper om PHP heen, die url's als /bla/test.php/1/2/3 gewoon correct afhandeld, maar dat vind ik eerlijk gezegd een nogal vieze oplossing, dus ik hou het liever bij een filter
Ik maak echter gebruik van apache's MultiViews uitbreiding, en aangezien ik de site thuis precies hetzelfde wil hebben, en ik geen multiviews ISAPI filter heb kunnen vinden, besloot ik maar om er zelf een te schrijven.
Anyway, dat is allemaal niet interessant, het gaat me nu om het filter zelf (dus opmerkingen als "waarom installeer je niet gewoon apache" mag je achterwege laten
Mijn filter is nu zover dat hij een url als /bla/test.php/1/2/3 omzet naar /bla/test.php. Echter, die /1/2/3 gaat verloren, en ik wil natuurlijk wel dat dat opvraagbaar is vanuit de CGI applicatie (PHP in dit geval). Apache zet deze extra info in PATH_INFO, alleen ik krijg het in mijn filter niet voor elkaar om die variabele te zetten.
Allereerst kun je dergelijke variabelen alleen maar opvragen vanuit je filter. Uit de MSDN maak ik op dat, als je de waarde van PATH_INFO opvraagt, er een URL_MAP notification door de filters wordt gestuurd, die de url omzet naar een fysiek pad. De documentatie hierover is echter wat summier, maar ik vermoed dat ik hier iets mee moet doen, aangezien IIS deze notification gebruikt om de PATH_INFO uit te vogelen (alsmede het daadwerkelijke bestand dat aangeroepen moet worden).
Heeft iemand enig idee hoe ik de PATH_INFO kan zetten voordat PHP aangeroepen wordt, zij het via die URL_MAP notification, of gewoon op een andere manier?
Dingen als SetEnvironmentVariable () werken niet, omdat IIS de var aanpast vlak voordat PHP invoked wordt. Bovendien denk ik niet dat IIS de variabelen 1 voor 1 gaat zetten in de huidige process, maar gewoon een array stuurt naar het childprocess (via CreateProcess ())
Momenteel neig ik naar een ander alternatief, namelijk een CGI wrapper om PHP heen, die url's als /bla/test.php/1/2/3 gewoon correct afhandeld, maar dat vind ik eerlijk gezegd een nogal vieze oplossing, dus ik hou het liever bij een filter
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.