Configuring custom CGI script to work with extensions

Hello litespeeder,

I’m trying to run a custom CGI script, that parses conditionally via extension - similar to PHP but not PHP. In my attempt to understand how this all fits together, I first followed this tutorial basically (except on Enterprise version)

It looks, however, as though this tutorial is geared towards running CGI scripts ‘standalone’ (ie, through rather than parsing separate files through the cgi script based on their extension.

For Apache, I believe that adding the appropriate headers below in .htaccess should have done the trick:

Action cgi-node ../cgi-bin/cgi-node.js
AddHandler cgi-node .jss

But whenever I access the file extension (.jss), it downloads the source code of that file rather than parsing it.

I have also attempted to create an external app with FastCGI in the console and call it in the Script Handler for .jss extensions, here is the external app:

Address: uds://tmp/lshttpd/cginode.sock (just invented this)
Max Conn: 1
Initial Timeout: 60
Retry: 0
Start by server: Yes
Command: /home/cginodetest/www/cgi-bin/cgi-node.js
Instances: 35
Run as: nobody / nogroup

But it seems to load for about 10 seconds and then download the same source file as before...

Files structure:
— cgi-bin
— — cgi-node.js
— public_html
— — .htaccess
— — test.jss

What am I missing here??

Thank you!
I get an error because the URL environment variable isn't set. But I don't think it's the script (although it probably *does* have more errors in it). I think so because I set up a simple hello world cgi script in perl which works fine

print "Content-type: text/html\n\n";
print <<HTML;
<title>A Simple Perl CGI</title>
<h1>A Simple Perl CGI</h1>
<p>Hello World</p>

Works fine on the command line and also if I call directly through And then I did the same thing with it - created an external app from it and then attached an extension to it in script handlers (.abc extension -> script handler -> "hello world perl" fastcgi external app") - and it behaved the same way. Just downloaded the .abc file
Thanks for your response, NiteWave. I managed to get it working... For any stragglers from the future, my issue was that I was under the impression that LiteSpeed, using 'external app', automatically generated the required scripts to get fastcgi working *from* a regular cgi script. I didn't realize that I had to actually set up the *fast*cgi server myself which then litespeed then could launch.

My ultimate goal was to get Deno working as a fastCGI script similar to PHP, and I managed to do that by setting up a deno fastcgi server (there is a fastcgi module for deno), launching that which listens on some localhost port and having LiteSpeed hook into that through their external app. Then whenever my fastcgi deno app gets a request from litespeed, it dynamically imports the file specified in the request call and parses it.

Also used ETA (templating engine) to be able to parse server-side typescript through <% %> tags

I haven't been able to get litespeed to auto-start the script for me however. I have only been able to run it externally and have litespeed connect to it. Not sure why. But maybe that's for a later day. According to the debug logs litespeed manages to launch the server, connect to it, but then it throws a 503 without any explanation... Hm.

Is it possible to see the console log output from a litespeed-daemonized fastcgi application?


Staff member
503 error most likely backend issue, check backend log for any hint.
In general, if you try something beyond the following, it may or may not be supported.

For example, for node.js, LSWS only does proxy to the backend. nothing else. You will need to test backend node.js to make it fully function.

get Deno working? Java script? a node.js server? If so, The same rule, get your node.js working, setup LSWS to be reversed proxy to it.