[Xitami] Small modification to ISAPI support

[Russel Olinger]

Interesting.  For your example that didn't work, you might also be able to 
add an extension filter to your configuration file and it might 
work...though in the end your rewrite methods are probably much better.  But 
give it a shot and see if this works.

In the defaults.cfg file add a filter extension
[Filter]
    .php=c:\php\php.exe
    .pl=c:\perl\bin\perl.exe
    .shtm=perlssi
    .shtml=perlssi
    .ssi=perlssi
    .dll=\true\path\isapi.exe

and then in your CGI alias section do something like:
> /test  ->  /new/true/path/testisapi.dll

The alias will reference the .dll file, then the [filter] section should 
initiate the isapi.exe file.  In your examples, what exactly is isapi.exe 
and testiasapi.dll or register.dll doing?  I imagine isapi.exe is to *.dll 
as perl.exe is to *.pl.  But the .dll files you are using, they sound like 
MS OLE files...now that I think of it, if you get the above to work then 
there is a good chance the entire cgi alias step can be bypassed as the 
simple [filter] will provide all needed associations.  though the file would 
still need to have an extension of dll.

Without the cgi alias http://domain/register.dll should trigger the 
isapi.exe, but the dll would be needed.  However, I do believe the 
configuration is parsed, even in memory, sequentially... so you could 
literally put a .*=isapi.exe at the ed of the filter section gauranteeing 
that if another extension isn't matched first, then Xitami will default 
everything to .*=isapi.exe.

How much faster is ISAPI versus CGI - and what language are the dll's 
written in?  At least for me, this method you have described is new to me.

Let us know.

----- Original Message ----- 
From: "JLIST" <jlist9 at gmail.com>
To: "Russel Olinger" <rolinger1 at hotmail.com>; <xitami at lists.xitami.org>
Sent: Wednesday, April 30, 2008 12:07 PM
Subject: Re[2]: [Xitami] Small modification to ISAPI support


> Hello Russel,
>
> Sorr for not being clear. My change is for the ISAPI add-on listed
> on the add-on page, not for xitami itself. Basically I need a high
> performance mechanism to serve dynamic pages (so, no CGI) on Windows.
> (I use FastCGI on Linux but that's not an option for Xitami.) I suppose
> I'll need to use LRWP. I find that the ISAPI add-on allows me
> to run ISAPI DLLs as LRWP and that ISAPI is easier to write than
> a complete LRWP. I think I'll be writing some ISAPI DLLs instead.
> But with the ISAPI add-on, it always shows the DLL name in the URL,
> hence why my change to remove that.
>
> I am new to xitami and I wasn't aware of CGI aliasing. Howerver,
> it seems to work only for CGIs. I tried it with ISAPI add-on and
> it didn't work. CGI aliasing doesn't really work the same way
> URL rewriting does.
>
> This didn't work:
> /test  ->  /isapi_exe/testisapi.dll
>
> URL rewriting (I use mod_rewrite on lighttpd on Linux) is more
> generic and more flexible. You can specify a regular expression
> to do the work (and more) that you described with the .pl CGI.
> It works with all URLs (cgi, fastcgi, scgi, static files ...)
> It also allows you to redirect all requests (/*) but some exceptions
> (e.g. /images/*) to your app at, e.g. /myapp.
>
> Jack
>
> Wednesday, April 30, 2008, 9:30:52 AM, you wrote:
>
>
>> JLIST:  Could you explain that a bit more?  I get the gist of it but I
>> assume you are also compiling our own Xitami and are able to modify the
>> source.  For us non-compiled users I am not certain we can use that 
>> method.
>
>> So instead, I do my own version of URL rewrites through Xitami's CGI
>> aliasing.  It works just fine and still provides you with all the 
>> necessary
>> PATH_INFO and perl $ENV of the alias - not of the actual called script
>
>> Example:
>> /showArticle    /cgi-bin/postShow.pl
>
>> A URL example would be:
>> http://www.foo.com/showArticle/cars/classic/1965-Convertable-Corvette_12345.html
>
>> /showArticle calls the "/cgi-bin/poswShow.pl" script, in the script I 
>> parse
>> the PATH_INFO environment variable to grab all the necessary ID info 
>> about
>> the URL to call up the correct article.  In this case, "cars" and 
>> "classic"
>> translate to category and forum IDs, then grab the actual article ID 
>> "12345"
>> to call it up to the user.  Using the CGI alias method, the PATH_INFO
>> environment variable is conveniently everything AFTER the /showArticle
>> alias.
>
>> So PATH_INFO = /cars/classic/1965-Convertable-Corvette_12345.html
>> Parse everything on "/" into an array: @array = split(/\//,$PATH_INFO)
>> SPLICE the first empty element: splice @array,
>> Then split the last element for the article ID, the text of irrelevant, 
>> its
>> only good for SEO stuff: @idInfo = split(/_/,$array[2]) ;
>> Remove the ".html" : $articleID = $idInfo[1] =~ s/\.html//;
>
>> Since I have never used Apache's mod_rewrite I don't know how much more
>> laborious the above method is...but its really not that difficult, each
>> script has to be slightly customized and you have to know what each part 
>> of
>> the URL stands for, but if you logically plan it out you can achieve the
>> whole thing pretty easy using just one called function to parse all your
>> vars for you.  It also requires that for every script you want to do URL
>> rewrites on, you must add a unique CGI alias for it.
>
>> Hope it helps.
>
>
>