I'm trying to download some cgi's from a remote server to my local machine using wget but wget always returns the error "No such file or directory". From a different machine this even returned "HTTP/1.1 404 Not Found". What's the matter with wget and cgi files? I can download other files without problems.

Thanks,

Daniel.

There may be some confusion here, about what a CGI is. When you reference a URL that is a CGI, it normally causes the web server to invoke a program that the website holds. The program then generates some output, usually based on input parameters passed to the CGI from the web browser. The output that the CGI generates is seen on your web browser. It should normally not be possible to download the code that is the CGI.
In your case, however, it seems that the result is exactly what the return status says it is; the referenced CGI URL does not exist. Perhaps your syntax is incorrect. Perhaps you can post the URL in question, in the format that you have been using.
--- rod.

Thanks Rod for your reply.

I agree in that the cgi seems to be executed by the web server when wget calls to it. Nevertheless, these cgi's are outside the cgi-bin directory and should be treated as simple binary files.

datehs.cgi is one of the cgi's that I want to download. Syntax:

wget http://www.opnode.org/projects/opn-o...bin/datehs.cgi

Thanks again for your help,

Daniel.

Well, when it comes to http, you can only see what the server serves. And most servers are configured to interpret cgi and then serve, and not to serve the cgi's themselves as plain text. So, it's the server what you need to configure correctly so serve these as text tiles and not as cgi's. Or just add the .txt suffix to these files. Cgi's are usually meant to be hidden. There's no need to make the life of exploiters and script kiddies any easier than it already is.

Actually, it is not the name that dictates whether apache runs the code or serves the file to the browser. The location of the file in the directory structure is the key. Normally, the directory named 'cgi-bin' in the server root is used to store CGIs. This is configurable, however. As estratos says, these file are outside the cgi-bin directory, and as such are just plain files, though not html pages, evidently.

It looks very much to me like estratos' problem is a server side issue, and without access to the server configuration, I don't think the files are accessible. There are at least couple of configuration issues that may be at play, but nothing that can be done from the client side. At least that's my analysis. The format of the URL being requested (assuming the the ... is only there for obfuscation) looks fine to me.

BTW, what happens if you try to access directories higher up the tree? Do you get a file index, a static page, an error status return code, other? If you see a file index, is the file(s) in question on that index page?

--- rod.

As you say, it's entirely configurable. I don't use apache regularly because lighttpd is enough for me, but if my memory serves correctly, mod_mime can do that. And maybe that's his problem. So I wouldn't discard it that fast.

I agree that's server side. And as said, you can only see what the serves serve to you. If the serves decide that the cgi is to be served as a cgi, then there's nothing you can do. In fact, that's probably completely intentional.

Thanks guys.

You seem to be right about your assumption. I've just posted a question on my provider's discussion board. Maybe other users can point me to the correct config parameter.

Thank you very much for your help.

Daniel.

The same applies to other programs that are supposed to be run on the server (and output of which is sent to the browser): they aren't/shouldn't be accessible for downloading. For example php files usually reside at the same public directories as html files and such, but if you try to download one, you don't get the original php file (the program) but the output of it -- which could be an empty file. This happens often when there's a "download file by clicking here" -link, which isn't a direct link but a link to a program (php or asp for example) and the user right-clicks on it and selects to "save file". What gets saved is not the file you'd get by clicking on the link (provided by the program) but a file named like the program, which is usually empty (so no program code there).

The server may of course be made to serve out the real program files like any other files, but I think it's fairly general, if there is support for running the given program type on the server, that any programs should be run and not "offered for download" -- they may produce output which the user then gets, but that's about it. This is why in server-side scripting languages such as php one can store passwords and other sensitive stuff (of course taking into account that the traffic between server and client may not be secure) without worrying about the end-user getting their hands on that information, not without getting criminal at least.

A lot of web service providers provide their customers with some CGI programs (guest book or e-mail-sending form for example), but they don't give the programs to the customers -- they just tell the URL where the program is and how you're supposed to use it.