cgi-dir is not working if its a subfolder within the staticdir

[rexxitall]

I have a project which looks roughtly like this:

/PAGE
/PAGE/htm
/PAGE/js
...

/PAGE/cgi-bin

if i define
websocketd.exe --port=8010 --cgidir=c:\wamp64\www\PAGE\cgi-bin --staticdir=c:\wamp64\www\PAGE
the cgi scripts will be delivered as plain text (their source code)

i got it working by definig it like this:

websocketd.exe --port=8010 --cgidir=c:\wamp64\www\PAGE\cgi-bin --staticdir=c:\wamp64\www\PAGE\htm
but this should be considered as hack
it also deliver c:\wamp64\www\PAGE\js ...
Well in my case i might be lucky by this but i guess no admin would be happy with it.

cgi folder should also work if they are within a page root folder.

And please make cgi scripts also work by their extension or a valid shebang.
To call vbs-cgi by a cmd wrapper is how to say "ugly".

I would also say thanks for this nice piece of software.
it can make a monster like electron completely obsolete.
Just start the browser in a mode without GUI and write a few small (cgi) scripts for interactions with the filesystem
wrap a starter bat around and save 100 MB of useless electron bullshit :)

That is how i use it :)

So, thanks again for it :)
Thomas

[Dart-o-s]

How did you make the "cmd wrapper"?
All my attempts to use cmd or powershell on Win11 failed.

I tried a GitBash shell script, I tried a .bat file and a .ps1 file. I have no easy way to make an .exe

[mathieu-aubin]

do yourselves a favor and run a virtual machine with any unix/linux type OS. You'd be better off with that in the long run as i can tell you are not bound by 'requirements' of a jobsite. Otherwise you wouldnt be asking such questions or having such issues.

[rexxitall]

[Dart-o-s] i use vbs.
start /B websocketd.exe --port=8012 "c:\windows\system32\cscript.exe" /NOLOGO "C:\wamp64\www\JEANIE\cgi-bin\vbscript_cgi.vbs" -loglevel=debug -header="Access-Control-Allow-Origin: *"`

The cgi-bin.vbs script parses all query and form data etc. and calls the worker which is script provided by get or post data in its context by execute global. By this i can concentrate the coding work just on the working code and do not have to parse all the cgi "decorations" in the worker script again and again. In fact all input data are stored in a uniform input dictionary so the worker script can get its input from a central point no matter what it might be. I use -header to overcome cross domain restrictions. In fact i run 3 "websocketd" to keep my folder structure as i want. 24 Megs are a cheap price if you compare to use things like electron. I use normal chrome (which is usually on the system) in app mode and websockd to enable the application to get local file access via cgi-bin. This makes such a application quite tiny and you can even distribute them by e-mail. Its some sort of poor man electron ;). One benefit is that i can develop the thing using a normal web server and a normal browser and then just have to zip the Apllication folder which also holds the bins of websockd and a batch file to make it run.

[Dart-o-s]

@mathieu-aubin You are completely right, but for my use case, it would get a bit more complicated. Let me think about it. I want to learn more about "multipass" (https://canonical.com/multipass) anyway. Probably the easiest solution. What irks me is that a simple *.bat does not work. I only want to print the IP address of the server into the index.html, so I can access it from my tablet. I abuse websocketd to download android builds from my laptop to my tablet, haha.

[Dart-o-s]

That is not how cgi is supposed to works. And frankly: I have no idea what you are doing there. If the browser requests: "balbal.html" the server is supposed to serve that from the static directory. If the browser requests: "super.exe" the server should execute super.exe from the cgi-bin directory, pipe the request into it and send the output back to the browser. You are doing something completely different. Has nothing to do with cgi. Best Regards, Angelo P.S. it seems you pipe the input and output for the whole server through your vb script (that does not really make any sense, to be honest - but funny idea

…

On Wed, Feb 19, 2025 at 7:10 PM Thomas Frank Ludewig < ***@***.***> wrote: [Dart-o-s] i use vbs. start /B websocketd.exe --port=8012 "c:\windows\system32\cscript.exe" /NOLOGO "C:\wamp64\www\JEANIE\cgi-bin\vbscript_cgi.vbs" -loglevel=debug -header="Access-Control-Allow-Origin: *"` The cgi-bin.vbs script parses all query and form data etc. and calls the worker which is script provided by get or post data in its context by execute global. By this i can concentrate the coding work just on the working code and do not have to parse all the cgi "decorations" in the worker script again and again. In fact all input data are stored in a uniform input dictionary so the worker script can get its input from a central point no matter what it might be. I use -header to overcome cross domain restrictions. In fact i run 3 "websocketd" to keep my folder structure as i want. 24 Megs are a cheap price if you compare to use things like electron. I use normal chrome (which is usually on the system) in app mode and websockd to enable the application to get local file access via cgi-bin. This makes such a application quite tiny and you can even distribute them by e-mail. Its some sort of poor man electron ;). One benefit is that i can develop the thing using a normal web server and a normal browser and then just have to zip the Apllication folder which also holds the bins of websockd and a batch file to make it run. — Reply to this email directly, view it on GitHub <#453 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BN5GTMEG572WXF7QZX7VSDL2QRYCFAVCNFSM6AAAAABVDBAYLSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNRYGQ3TAOJSGA> . You are receiving this because you commented.Message ID: ***@***.***> [image: rexxitall]*rexxitall* left a comment (joewalnes/websocketd#453) <#453 (comment)> [Dart-o-s] i use vbs. start /B websocketd.exe --port=8012 "c:\windows\system32\cscript.exe" /NOLOGO "C:\wamp64\www\JEANIE\cgi-bin\vbscript_cgi.vbs" -loglevel=debug -header="Access-Control-Allow-Origin: *"` The cgi-bin.vbs script parses all query and form data etc. and calls the worker which is script provided by get or post data in its context by execute global. By this i can concentrate the coding work just on the working code and do not have to parse all the cgi "decorations" in the worker script again and again. In fact all input data are stored in a uniform input dictionary so the worker script can get its input from a central point no matter what it might be. I use -header to overcome cross domain restrictions. In fact i run 3 "websocketd" to keep my folder structure as i want. 24 Megs are a cheap price if you compare to use things like electron. I use normal chrome (which is usually on the system) in app mode and websockd to enable the application to get local file access via cgi-bin. This makes such a application quite tiny and you can even distribute them by e-mail. Its some sort of poor man electron ;). One benefit is that i can develop the thing using a normal web server and a normal browser and then just have to zip the Apllication folder which also holds the bins of websockd and a batch file to make it run. — Reply to this email directly, view it on GitHub <#453 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BN5GTMEG572WXF7QZX7VSDL2QRYCFAVCNFSM6AAAAABVDBAYLSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNRYGQ3TAOJSGA> . You are receiving this because you commented.Message ID: ***@***.***>

[rexxitall]

I use the websockd to mimic something similar to electron. If the cgi-dir is outside you can not just zip the folder and deploy them. The cgi just do what a browser can not do. Real file write and load or native sqlite. Chrome is able to mimic a normal program window. Electron installs on each little program first a whole chrome instance. Bullshit ! The workaround is to start as much websockd as i need to have the folder in the same place. Works but is uncool. And yes such a program is zipped so small that you even can mail it. Unzip, start the start batch and you has a very nice GUI program for whatever purpose. The start batch also takes care of handlng the instances of chrome, websockd and so on. I think that is the real magic behind websockd. If you run something else i guess you will have enough money to tell a real server what he shall do with websocks.