Re: FastCGI and CLISP - clarification on a few aspects ?

Hello Pascal and thank you for the reply.

On Sun, Jul 22, 2018 at 3:48 PM, Pascal Bourguignon <[email protected]>
wrote:

>
>
> On 11 May 2018, at 16:06, C Habs <[email protected]> wrote:
>
> Hello clisp-list
>
> I ramble a bit, but please bear with me.
>
>
> Sorry for the late answer, but hey! My holidays start today ;-)
>

I'm sorry for my late response. I have been working on the problem and in
respect of your response too.



>
>
> I suppose I am asking for little bit of assistance/clarification in
> understanding CLISP implementation of FastCGI, of which I have done a fair
> bit (in terms of time) of searching and reading.
>
> One particular piece of hooking up CLISP was here -->
> https://www.phillipstreet.com/2013/01/dipping-my-toes-into-
> lisp-getting-common-lisp-with-fastcgi-support-working-with-apache/
>
> I was still unclear though on some aspects.
>
> Let me explain an expectation, as naive as it may be:  in a [plain] CGI
> context, I would expect it possible to have 1..n CLISP
> apps/programs/scripts doing various things, perhaps all with an extension
> of '.lisp' under a directory of cgi-bin on a webserver.
>
>
>
> Let me interrupt here.  NO!
> Never use file extensions for unix executables (scripts are executables)!
>
> Unix scripts should not have any file extension.
> They unnecessarily expose implementation detail (breaking encapsulation).
> They uselessly and incompletely mimic detail from the #! line.
> They capture insufficient detail to be useful at the system level (and
> aren't used).
> They clash with recommended Unix (and Linux) practice.
> They add noise to the command-level API.
> They are very commonly technically incorrect for the script.
> They give incorrect impressions about the use of the files they adorn.
> They aren't validated even for what little info is present in them.
> They interfere with switching scripting languages.
> They interfere with changing scripting language versions.
> They interfere with changing to presumably-faster compiled forms.
> They encourage naively running scripts with the extension-implied
> interpreter.
> They infect novice scripters with misinformation about Unix scripting.
> They ironically are only a problem when interpreted by humans.
>
>
> See more at:
> http://www.talisman.org/~erlkonig/documents/commandname-extensions-
> considered-harmful
>
>
Thank for the reminder :-)    Unfortunately some web server programs use an
extension to identify and invoke CGI scripts - arguably the extension just
being part of the filename after a period '.'  (as unnecessary as that may
seem).  I was referring to CGI 'programs/apps/etc' specifically  and
perhaps my words were poorly chosen.



>
> Now, in the context of CGI, since CGI are executables with specific
> properties, it may be accepted to name them with a .cgi extension.  This is
> a special case, like an application executable could be named with a .app
> extension (but notice that actually .app are file bundles, directories, and
> the actual executable is named without an extension).
>
> If you run a cgi from a command line, chances are it won’t work and won’t
> do what it should.  This is because this kind of executable require a
> specific call interface, using environment variables (and possibly stdin),
> and not command line arguments, and producing a very specific output on
> stdout, that won’t be usually readable by the user at the CLI.
>
> But you could also write a program that could use several interface. For
> example, it could behave as a CGI if the CGI environment is set up, and no
> command line option is given, or it could behave as a GUI application if
> DISPLAY is set and no command line option is given, or it could behave as a
> normal command in other cases.  Such an executable should not be named with
> any extension.
>
> So you see that the argument to name CGI with a .cgi extension is actually
> a weak one.
>
>
>
Fine. I understand your point.


>
>
> On receiving a request e.g https://myserver/cgi-bin/example1.lisp, the
> server would return whatever was the output of the example1 script (or any
> of the others that may get called).
>
> Each script file might be something along the lines of:
> -----
> #!/usr/bin/clisp -K base -m 10M
>
> (some lisp forms to evaluate and return some plain text, or html, or
> whatever)
> -----
>
> I have succeeded to an extent in creating and operating this 'expectation'
> on thttpd and lighttpd.
>
>
> The point being, that I just drop each lisp script in the cgi-bin folder
> and call which ever using a url and that's it as such.
>
>
> The slow part in the usual setup, is forking and launching a new process
> for each request.  This is what fastcgi aims to optimize, by launching the
> cgi process once, and then using IPC (sockets) to send the requests and get
> the output back.
>
>
> > Now when it comes to FastCGI and please correct me if I am wrong, this
> way
>
> of working changes. What is required is a separately [from the webserver]
> and persistently running CLISP FastCGI process and one that the webserver
> communicates with using sockets.
>
>
> Yes.
>
>
> There is example code here of a CLISP 'program' -->
> https://clisp.sourceforge.io/impnotes/fastcgi.html#fcgi-example
>
> On a server, e.g. lighttpd (as thttpd only has standard CGI), a fastcgi
> config option for calling fastcgi 'programs' would detail the url 'path' to
> be used to invoke a connection to the CLISP Fastcgi process, the socket to
> use for the connection and the 'binary' itself e.g. the CLISP fastcgi
> enabled program.
>
> Where I need clarification/assistance, thinking back to the 1..n standard
> CGI scripts in a cgi-bin setup, does each CLISP CGI script in cgi-bin, need
> converting to a CLISP FastCGI program as in the linked example code, where
> each will then require starting up to run persistently before it can be
> called by the webserver ?
>
> This would then require a configuration setting for *each* program in the
> webserver (path, socket, program name etc), yes ?
>
>
> Yes.
>
>
> It seems not so simple/flexible for want of better words, compared to just
> dropping a script with a .cgi extension in a cgi-bin. I think some of my
> confusion is from reading about FastCGI PHP scripts/programs,  where PHP
> appears to have an inbuilt FASTCGI 'lauching' (my description) program
> built in that can run any script with a .php extension...but maybe I've got
> that wrong.
>
>
>
> https://en.wikipedia.org/wiki/FastCGI
> http://httpd.apache.org/mod_fcgid/
> http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html
>
> What you’re missing is that it’s the fastcgi server process, itself
> launched by the fastcgi module in the web server, that will launch and
> manage the cgi processes.  So you don’t have to do anything, and it remains
> as simple as with normal CGIs.
>
>

It would seem so, but my issue is that there is very little documentation
to illuminate configurations when actually hooking up CLISP FAST-CGI to the
webserver.

Take Lighttpd for instance.  The fast-cgi config for  PHP running as
FAST-CGI is here :
https://redmine.lighttpd.net/projects/1/wiki/Docs_ModFastCGI

One parameter is the  'bin-path'  that points to the php-cgi program and
*not* the CGI script that would be invoked.  Then in some URL from an agent
is identified the script to call e.g.
/domain/apps/scripts/somescript1.cgi, /domain/apps/scripts/somescript1.cgi
and the  php fast-cgi process identifies which script. locates it and
executes it.  That's as how I see it.

When it comes to CLISP,  I am still wondering what should go in the
'bin-path' setting   and   would the rest of it then work as described for
php above, in that  the CLISP fastcgi process would identifiy the script
being called in the URL and run it  (for want of a better
description)....just as ordinary CGI would.


I feel more experimenting coming on,  but if anyone has hooked up CLISP
with FASTCGI (especially with Lighttpd server) and can share their config
that would be really useful.

Apologies for my novice understanding. I will get there....I hope :-)

Regards
Habs
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
clisp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/clisp-list