Calling a revServer script from inside a .html page?

Keith Clarke keith.clarke at
Sat Dec 18 13:01:07 EST 2010

Thanks, for the clarification on how the CGI process works and how mod_rewrite & .htaccess can be used to tweak things. 

I'm not sure about these being essential to enable revServer - unless they do more than manage the script hand-off to the revServer engine. As I have full access to my server, I've adopted/adapted the virtual host scenario in this lesson And, plagiarising heavily from Devin Asay's OSX Server configuration, I was able to follow the Apache security recommendation of avoiding .htaccess files and overrides if possible. The CGI script handler and action directives are in my server's 'master' httpd.conf and so I have server-wide support for irev-script CGI calls for pages with a '.irev' mime-type suffix. I'll be publishing a how-to for revServer on OSX very shortly.

However, the .htaccess workaround might be OK (and low-risk) for a low-traffic site on a non-production server - so it might allow me to rev-enable the OSX Wiki Server pages on my development box. I'll experiment with this - and if it works, I'll add it to my 'RevServer on OSX' How-to guide.
On 18 Dec 2010, at 14:59, Richard Gaskin wrote:

> Keith Clarke wrote:
> > Pierre, Thanks for the clarification. Not quite the answer I was
> > hoping as I want to rev-enable existing auto-generated pages where
> > I can't change the page mime-type from html.
> That's how just how Apache works with RevServer and AFAIK any other CGI-like process that you want the server to invoke for further processing.
> With mod-rewrite rules in a .htaccess file you can do all sorts of stuff.
> RevServer installs require this anyway; it's included by default with accounts, and to use RevServer on any other server you need to put those rules into a .htaccess file; without them, Apache would have no way to know to hand off those page requests to your CGI.
> Here's the one I use at
> RewriteEngine On
> RewriteBase /
> RewriteCond %{REQUEST_FILENAME} -f
> RewriteRule ^(.+)\.irv$  /cgi-bin/irv.cgi?%{REQUEST_FILENAME} [L,NC,QSA]
> In brief, it says to take any request for a file ending in .irv and hand it over to /cgi-bin/irv.cgi for further processing before passing the results back to the requester.
> mod_rewrite is very powerful, and well worth the modest amount of time needed to become familiar with it.   Like most Apache modules, it's well documented all over the web.  The Apache docs are a good start:
> <>
> ...and there's a ton of other great examples and tutorials to be found.
> One challenge with using .html is that you may want to have some static pages there, and just replacing ".irv" with ".html" in the rules above will redirect all .html requests to your CGI, which can eat more processing time than necessary if you leave it up to your CGI to determine whether to do further processing or just hand the contents back to Apache.
> That's why most configs specify certain file types for specific additional processing (e.g., ".php" for PHP, ".asp" for Microsoft's DB setup, ".irev" for RevServer, etc.).
> But if you really want your CGI to process all .html requests, you can modify the rules above and drop it in a .htaccess file on your server and you're good to go.
> One useful thing to keep in mind is that any mod_rewrite rules in a .htaccess file affect only the directory that the .htaccess file is in and any subdirectories within it.  So if you wanted to have one folder that gets preprocessed with a CGI while using other folders for static pages, just put your .htaccess file in the folder where you want the pages processed and the others will be left for Apache to handle by itself.
> --
> Richard Gaskin
> Fourth World
> LiveCode training and consulting:
> Webzine for LiveCode developers:
> LiveCode Journal blog:
> _______________________________________________
> use-livecode mailing list
> use-livecode at
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:

More information about the Use-livecode mailing list