Add support for simple CGI about caddy

[jung-kurt]

I've written a CGI plugin for Caddy (repo and documentation). It's been working fine for me, but I thought I would let the people following this issue take a look before making a pull request.

[dbohdan]

You can use the FastCGI wrapper script developed for Nginx (direct download link, fork on GitHub) to run CGI programs with Caddy.

Download the original version of the script, run it as a daemon and put the directive

fastcgi /cgi-bin localhost:8999 {
    ext   .pl
    split .pl
}

in your Caddyfile. It will execute CGI programs found in the subdirectory cgi-bin in your server's root directory.

I haven't examined the security implications of this.

[ua-code-dragon]

Let me speak in defence of simple CGI too. It is much useful than many people think.
In particular, I try to use caddy under windows as a single web service for a lot of web interfaces and lightly loaded APIs. A CGI interface with manageable environment would be to the point.

[jung-kurt]

@mholt -- yes, I'll submit the CGI plugin documentation for the new website. My email can be found in the project license.

[dbohdan]

I've published a ready-to-run example configuration at https://github.com/dbohdan/caddy-cgi.

[ua-code-dragon]

Ok. I'm rather old dog, but I have a good skills in C, perl and python, so I hope I can handle golang.

[jung-kurt]

Thanks, @mholt -- I'll rework the syntax and submit a PR in the next couple of days.

[mholt]

@Fastidious Not yet, launch event details are here: https://www.facebook.com/events/1413078512092363/

[mholt]

I thought about CGI, but given that it's an older technology and (hopefully) on its way out, I didn't want to implement it... however, I'm open to the possibility of adding it. Go has a cgi package in the std lib: http://golang.org/pkg/net/http/cgi/

If you or somebody would like to hack together a CGI middleware and see how that would work, I imagine it wouldn't be terribly difficult - probably easier than the FastCGI one, anyway, with some overlap. Or I could get around to it later.

[gabsoftware]

Thanks for considering it!
I guess I should learn the Go language first if I decide to do it :-)
By the way I could get around my problem using the proxy directive.

[mholt]

Well, I've got good news for you @gabsoftware. I was talking to someone over dinner tonight who mentioned that CGI isn't always bad - it's fine if you're just making requests once in a while; for him, a valid use case is to only have to make CGI requests a few times per day. (Obviously, CGI isn't so great when every user spawns a process.) So, it's looking more plausible that CGI may be added to Caddy.

So do you need it to work just like the FastCGI one, with path splitting and index files and stuff then?

[gabsoftware]

Yes, that would be great :)

CGI is obviously outdated and we should avoid to use it, but still, supporting it would help a lot of website to migrate to your web server ;-) Although, as I said, I could fix my issue using the Proxy directive.

By the way, I had a look at the code of the FastCGI module and I have to admit that I had no idea about how to use it as a base for simple CGI.

Thanks for helping to make the Web a better place.

[mholt]

^ That's clever.

Well, I'm going to close the issue since I haven't had more than 2 requests for it, like, ever... so maybe someone could make it as an add-on but I don't feel I want to build it into Caddy at this point. Just doesn't seem like as useful a technology going into the future.

If anyone disagrees, that's fine: it shouldn't be a difficult add-on to make, and I'd be happy to publish it on the website too. I just don't have the time to do it myself.

[kaihendry]

Archlinux has a https://wiki.archlinux.org/index.php/Nginx#fcgiwrap but by default it uses a file socket. I wonder if this can be made to work with Caddy?

[k4ml]

I post this in forum - https://forum.caddyserver.com/t/equivalent-of-websocket-directive-for-normal-web-request/998

My primary intention is to avoid having another daemon that I have to start first before running caddy. The websocket directive already awesome but feel short when you can't have something along the same theme to just handle some web requests.

[mholt]

This is probably a somewhat trivial plugin to implement, if someone wants to do so. (And in a few months we'll have a whole new website to make publishing plugins much easier.)

[wendigo]

If you need any help @hattifattener we are here :)

[k4ml]

Just set up my golang environment and I'm thinking of looking at this as my first go lesson ;)

Do you think the websocket extension can be a starting point to implement this ?

[mholt]

Yes, you could use that as a template I would say. Good luck! (And merry Christmas!)

[mholt]

@jung-kurt That looks really good. Want to submit a PR to add the directive to the list in plugin.go?

Also, see if you can flatten the Caddyfile syntax (the app part that opens a nested block). We're removing support for nested blocks.

[k4ml]

@jung-kurt Any notes on how to test this ? I try adding it to run.go:-

diff --git a/caddy/caddymain/run.go b/caddy/caddymain/run.go
index ba9aa26..f07514f 100644
--- a/caddy/caddymain/run.go
+++ b/caddy/caddymain/run.go
@@ -22,6 +22,8 @@ import (

    "github.com/mholt/caddy/caddytls"
    // This is where other plugins get plugged in (imported)
+
+   _ "github.com/jung-kurt/caddy-cgi"
 )

and then run go get && go build. The build succeed but still when running caddy, got error:-

Caddyfile:2 - Parse error: Unknown directive 'cgi'

[mholt]

Don't forget to add the directive to the list in the HTTP server. 😉

[k4ml]

Thanks, it work ! But using wildcard seem to give 500 error:-

cat Caddyfile
http://localhost:9000
cgi /cgi/*.sh /bin/bash /tmp/cgi/{match}

ls -lh /tmp/cgi/
total 16
-rwxr-xr-x  1 kamal  wheel   170B Feb  7 09:09 customer.sh
-rwxr-xr-x  1 kamal  wheel   166B Feb  7 09:09 user.sh

cat /tmp/cgi/user.sh
#!/bin/bash

printf "Content-type: text/plain\n\n"

printf "USER REPORT\n"
printf "PATH_INFO    [%s]\n" $PATH_INFO
printf "QUERY_STRING [%s]\n" $QUERY_STRING

exit 0

[jung-kurt]

It looks like {match} will be /cgi/user.cgi and the command will be /bin/bash /tmp/cgi/cgi/user.cgi. I think you want the directive cgi /cgi/*.sh /tmp/{match}.

Also, note that you can omit either the shebang line in user.cgi, or the direct reference to /bin/bash in the cgi directive.

[k4ml]

Hmm, look like the match containing my cwd:-

07/Feb/2017:10:35:50 +0800 [ERROR 0 /cgi/user.sh] /bin/bash: /tmp//Users/kamal/go/src/github.com/mholt/caddy/caddy/cgi/user.sh: No such file or directory
07/Feb/2017:10:36:06 +0800 [ERROR 0 /cgi/user.sh] /bin/bash: /tmp//Users/kamal/go/src/github.com/mholt/caddy/caddy/cgi/user.sh: No such file or directory

pwd
/Users/kamal/go/src/github.com/mholt/caddy/caddy

[jung-kurt]

Right you are, @k4ml. I just commited a fix in which the Caddy document root is not prepended to the {match} substitute. I will add a test to cover this.

One additional note I will document. Just as static resources have to be readable by Caddy, a CGI script needs to be executable by Caddy. If you opt for a standalone script (compiled or a shell script with a shebang line), it will need to be marked as executable.

[reddec]

@jung-kurt thanks a lot! Did you provide a pull-request? It seems to be very useful feature

[jung-kurt]

Thanks, @reddec. Yes. It's been merged and is, I believe, ready to be part of the build system with the next release.

[mholt]

@jung-kurt Want to add your plugin to the new Caddy website which will be launched soon? How can I email you.

[Fastidious]

Has the new site launched? Awaiting for this plugin to resurrect my old wiki (Perl based). 😄

[dbohdan]

Since the CGI plugin is v1-only and defunct, I have updated my FastCGI-to-CGI proxy example for Caddy 2.