Forum

Howdy,
Cheers for hiawatha. Seems small and simple and works, only thing that slightly annoys me is the CGI (just because I prefer the "is the file executable? exec it" approach instead of dispatching based on file extension - what if I have a binary cgi?).
Anyway, I was wondering if there is a mailing list or feed I can subscribe to to hear about version updates/vulnerabilities, since I'll never remember to keep checking the site
Thanks,
-sqweek

Not all CGI 'programs' are executables. PHP scripts for example. They're just text files. And to know whether a file is a PHP script, a Perl script, a binary or just a normal HTML file, there is practicly no other way then to use extensions.

If you want to receive update notifications, go to freshmeat.net, create an account if you don't have one and 'Subscribe to new releases' of Hiawatha.

if(access(X_OK, filename) == 0) {runcgi(filename);} else {putdata(filename);}
Thanks for the freshmeat info.
-sqweek

If it were that simple, I would have done it. Trust me.

What problem does it present, out of curiosity?
-sqweek

A normal CGI binary can be executed, using one of the exec() family. A PHP script must be executed by executing /usr/bin/php-cgi with the PHP script as the parameter, a Perl script by executing /usr/bin/perl with the Perl script as the parameter, etc. If a file is requested which can be executed, but doesn't have an extension, how do I know how to 'execute' it?

The kernel takes care of that. exec has special handling for files that begin with #! (ie, it treats the first line as an interpreter).
Try it:

$ cat >hi
#!/bin/cat
Hello world!
$ chmod +x hi
$ ./hi
#!/bin/cat
Hello world!
$ strace -e trace=process ./hi
execve("./hi", ["./hi"], [/* 83 vars */]) = 0
#!/bin/cat
Hello world!
exit_group(0) = ?

Or equivalently:

#!/bin/sed s/Hi/Hello/;s/there/world/
Hi there!

Anyway, I'll almost certainly forget about this thread while you're away, the only reason I've remembered so far is because I kept the browser open
You can get me on sqweek@gmail.com if there's anything left to say. Enjoy the holiday!
-sqweek

The problem is that not all scripts start with #!<binary>. PHP for example doesn't need it. If you run the PHP binary with the PHP script as the parameter, it works fine (with Apache's mod_php for example). As you see, it's a bit more complicated than just leaving exec() with the problem.

Sure. It's not necessary from PHP/Python/Perl/Sh/Ruby/whatever's point of view, they just see it as a comment. The reason you want #!<binary> is *precisely* so that exec works.
My point is, unix already provides a mechanism for specifying a script's interpreter. Having hiawatha use its own convention is a needless complication (and hiawatha is far from alone in this respect, but popular != correct). And I *still* don't see how you can support a binary cgi - what "interpreter" exists here? Ah, I guess /usr/bin/env works...

> As you see, it's a bit more complicated than just leaving exec() with the problem.

It's more complicated *because you make it more complicated*. There is NOTHING wrong with simply relying on exec.
-sqweek

The problem is that I only make the webserver, not the websites. Tons of webapplications have been written without the #! in every file. If Hiawatha requires #!, nobody is going to use Hiawatha because they're not going to adjust hundreds of files just to use Hiawatha. And what about the Windows platform? Windows doesn't support #!.

A binary CGI doesn't need an interpreter. It consists of machine code, which a computer can read without interpretation. The 'interpretation' has already been done, like a compiled C program.

I'm not making it more complated, it really is a little more complicated than just using exec(). There is not something really wrong with relying on exec(), it's just that if I do so, I make my webserver less attractive as an alternative for other webservers.

> And what about the Windows platform? Windows doesn't support #!.

"Hiawatha is a webserver for Unix." -- http://projects.leisink.org/hiawatha


> A binary CGI doesn't need an interpreter. It consists of machine code, which a computer can read without interpretation. The 'interpretation' has already been done, like a compiled C program.

I know that! My point is if I want to use a binary cgi with hiawatha, I have to (a) give it a predictable extension (which already turns me off) and (b) provide hiawatha with an interpreter for that extension. Or did I miss something?
-sqweek

Hiawatha also works under Windows (via Cygwin). My remark was also more meant as a webserver-general remark, not a Hiawatha specific remark.

It is a common fact that webservers work via file extensions (mimetypes). It is necessary to determine the file type because of the required Content-Type in the response. And if static files work via extensions, why handle CGI in a different way? I think it's better to just accept it. You won't find a good webserver which doesn't work via extensions.

There are two types of CGI: the binaries and the scripts. Binaries are configured via CGIextension (no interpreter is required) and scripts via CGIhandler (a interpreter is required).

CGIextension = cgi
CGIhandler = /usr/bin/php-cgi:php,php4
CGIhandler = /usr/bin/perl:pl

What if I add the following option:

  NoExtensionAs = <extension>

With this option, make Hiawatha treat files with no extension as if they had the specified extension. If you use:

  CGIextension = cgi
  NoExtensionAs = cgi

would make Hiawatha handle every file without an extenion as a binary CGI. You just have to add #! to every CGI script in order to make them work. That would solve your 'problem', not?

Well, cygwin provides a suitable exec(), no?



Um, because cgi is nothing like a mime type?



Like I said, popular is not the same as correct.



Ah, I see. The lack of transparency here (ie, a single option scheme doesn't work for both binaries and scripts) is part of what I don't like about the whole thing.



I'm not fond of option proliferation, personally. More options = more documentation = more maintenance and a worse signal to noise ratio within the documentation (since any one person probably isn't interested in all available options). I certainly wouldn't like to feel responsible for adding more options to hiawatha (how do you think httpd configurations get bloated? ).



For the most part, yes. But it still imposes an arbitrary naming restriction on my scripts - if I drop a cgi script that contains a . into my webroot I need to provide a corresponding option to hiawatha. What if you just fell back to standard unix behaviour when encountering an executable file with no associated extension?

Thanks for your time, Hugo.
-sqweek

No! That's the thing you keep on misunderstanding. A binary CGI is totally different from a PHP CGI script. It's not because I choose to, but because the world has decided so.

CGI describes an _interface_. Whether it's a binary executable or php script, both are exec()able, both read request information from the environment/stdin, both write response information to stdout. Where's the difference?
-sqweek

No, they're not!! Becuase you place #! in every PHP file, that doesn't mean that the rest of the world does. Most PHP files and websites DON'T use #!. They start with HTML or with <?php. If Hiawatha is to be able to server those pages/websites, some technique has to be used to determine the type of the CGI. Hiawatha, and all other webservers, use extensions for that.

I understand that, and I understand it makes sense for you to take the pragmatic approach that allows those scripts to work.
I expect you see where I'm coming from aswell - a perfectly sensible interface for defining a script's interpreter via #! existed long before php or cgi, the fact that it wasn't used and a whole new convention was created instead is just the usual divergence/retardation that surrounds modern software.
That's reality. My only problem is, I have to care about the stupid inflexible new convention (I'm not a httpd enthusiast, so the more it embraces the existing environment the better), when it would Just Work? if Hiawatha did the simple thing and fork+exec'd (and like I said previously, this doesn't preclude the use of extensions).
-sqweek

I think the only way to make you understand, is for you to build a webserver yourself. Make it support binary CGI and all sorts of CGI scripts (PHP, Perl, Python, etc), make it support FastCGI and make it available on Linux, BSD, MacOS X and Windows. After that, you'll understand why things are done the way they are done.

I understand you want things to be easy. But sometimes, things just aren't easy. Supporting CGI and FastCGI on multiple platforms is simply a complex thing. And these are my last words on this matter.