HowStuffWorks "How CGI Scripting Works"
this i think was a bit interesting and i would like to get some better tutorials for cgi scripting using c.
anyone knows of good tutorials. ?
thanks for the time.
HowStuffWorks "How CGI Scripting Works"
this i think was a bit interesting and i would like to get some better tutorials for cgi scripting using c.
anyone knows of good tutorials. ?
thanks for the time.
PERL, would be my choice here, but this may get you started, a few seconds on google/bing should point you to something like:
CGI-C Tutorial
This may be a bit more intuitive:
HOW-TO Write a CGI Program in C/C++
Using C for CGI is almost a 100% waste of time. Not to mention it's dangerous, and poorly suited to string parsing. I would suggest Perl.
I am not sure what you mean by dangerous, obviously there are some gotchas to contend with such as validating user input and use of stored data and retrieving it per page. C is used for systems with vast CGI handling. But for most users, I agree, PERL would be ideal.Originally Posted by zacs7
thanks.
i know perl would be better. i just learning c right now as the first language so i wont jump over to perl right now.
later when i feel i can master c a lot better i plan to learn perl. then i would have the experience from this already when i start learning perl.
thanks a lot for the links. i bookmarked them.
There's nothing wrong with wanting to do this. It is true that string parsing is easier in perl if you know C and perl, but it will be much harder if you don't know perl!
And it is just wrong to say that it is "dangerous" to parse strings in C. You might as well say it is "dangerous" to do anything in C...
There is nothing more to CGI than string parsing, either. No matter what language the program is, it works the same way:
-you read the form data from STDIN, ie, it is *exactly* the same as writing a program to read data from the keyboard, since that is STDIN. The web server delivers the data to the program exactly as if someone had ran it and started typing.
-you write the new html page to STDOUT, using printf() or whatever. Again, it is *exactly* the same as if the program were writing text to the user's console, which is the normative STDOUT.
That may not be totally clear to people who have only done CGI using perl with the CGI module, but it is the case. If you do CGI in perl without using the CGI module, it works just like I just described; what the CGI module was doing was parsing the raw form data (eg, "name=mk27&avatar=spinningcube.gif") from STDIN.
Of course, that is kind of handy which is why it is nice to use a module or library. I am sure there is one for C, I've never tried...but as I said, it is Pretty Darn Simple even with no module or library. You just have to get a grip on using HTML and parsing form submission data.
C programming resources:
GNU C Function and Macro Index -- glibc reference manual
The C Book -- nice online learner guide
Current ISO draft standard
CCAN -- new CPAN like open source library repository
3 (different) GNU debugger tutorials: #1 -- #2 -- #3
cpwiki -- our wiki on sourceforge
Actually, I believe the query string (and similar information) is read from environment variables, not from stdin. stdin is only used for post data for - the post data. And not only the html is sent to stdout, also the headers (followed by an empty line and then the html data).
stderr can also be used, at least when using apache, it will write the output from a cgi stderr to the apache error logs.
Well if by query string you mean the input from from the form, eg, if I enter my name and a number the post data is "name=mk27&number=666", that is what comes thru stand-in, ie, 95% of what you are doing with cgi is just parsing stdin. There is not much need to be using env variables.
AFAIK, having written a few dozen cgi scripts in regular use, using only stdin and stdout, you do not have to send a http header or anything other than html. That output is handed to the web server which runs the script and the server appends an http header and passes it to the network layer which does the tcp/ip wrapper.And not only the html is sent to stdout, also the headers
Last edited by MK27; 07-14-2009 at 01:45 PM.
C programming resources:
GNU C Function and Macro Index -- glibc reference manual
The C Book -- nice online learner guide
Current ISO draft standard
CCAN -- new CPAN like open source library repository
3 (different) GNU debugger tutorials: #1 -- #2 -- #3
cpwiki -- our wiki on sourceforge
A query string is part of the URL. After the questionmark. This is not posted and is quite commonly needed in scripts. This is read from the environment variables.
And about the headers... This tutorial:
HOW-TO Write a CGI Program in C/C++
Shows outputting "Content-type: text/html". And I remember not doing that - the output in the browser would not be the html page, but rather the text of the html. So "<b>test</b>" would actually show "<b>test</b>" and not a bold "test".
So I reckon you need at least the Content-Type header. For firefox, at least.
If I remember correctly.
Yeah, that's the form input data and it is posted to STDIN in exactly the string you see following the question mark, using "=" and "&" as delimiters. That is what you parse if you do not use a module to do it for you. I promise. Try it.A query string is part of the URL. After the questionmark. This is not posted
It may *also* be available in environment variables.
About this you are totally correct. I had forgotten that little detail! That is why it is almost always the last line of an HTTP header. So if you have a text file template you want to use with cgi, it should start:
maybe not exactly thatCode:Content-type: text/html <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml111/DTD/xhtml111.dtd"> <!-- for use by mkdb.cgi --> <html xmlns="http://www.w3.org/1999/xhtml"> <head>but this should be clear enough. I suppose there are additional HTTP fields that it maybe possible for you to add but most of it is already dealt with.
Last edited by MK27; 07-14-2009 at 07:47 PM.
C programming resources:
GNU C Function and Macro Index -- glibc reference manual
The C Book -- nice online learner guide
Current ISO draft standard
CCAN -- new CPAN like open source library repository
3 (different) GNU debugger tutorials: #1 -- #2 -- #3
cpwiki -- our wiki on sourceforge
No, it's not the form data. Or at least, not always.
If the form's method is GET then indeed, the query string will become part of the URL. Usually, however, POST is used. Then it won't become part of the URL.
I am quite sure that the POST data is sent to stdin, while the requested headers (of which the URL is part) are stored in the environment variables. Eg:
"Posted data" will be fed through stdin, while the requested URL (again, of which the query string is part) through the headers. Or are you saying the application is supposed to parse the HTTP headers again (as our browser will have done just that)?Code:POST /something?querystring_here=1&abc=123 HTTP/1.1 Host: somehost.com Content-Length: x Posted data
>> Using C for CGI is almost a 100% waste of time. Not to mention it's dangerous, and poorly suited to string parsing. I would suggest Perl.
Perl over C? Give me a break. The only reason I would use Perl is if I *had* to. Given a choice in the matter C would be much preferable. Going for the other option would be like choosing a squirt gun over a rocket launcher!
Code:#include <cmath> #include <complex> bool euler_flip(bool value) { return std::pow ( std::complex<float>(std::exp(1.0)), std::complex<float>(0, 1) * std::complex<float>(std::atan(1.0) *(1 << (value + 2))) ).real() < 0; }
Lol true, but what if you had to inflate a balloon with said weapon at an amusement park to win a stuffed lion for your family and not blow up the town in doing so. Then you must consider what tools/weapons are available that can accomplish the same task with less effort and time.
Myself I prefer "hot car" analogies:
Going for the other option would be like choosing a pinto over a real red ferrari!
Altho I think you may need your head examined on this one, Sebastiani. While I agree there is nothing wrong with using C to do cgi, there is a reason 95% of it is done with perl in real life AFAIK. You will have a big problem fitting your rocket launcher through the door and wind up getting thoroughly soaked with the squirt gun about twenty or a hundred times before you can assemble it properly.
You can write a functional cgi script in about 5 lines of perl. Using a "lower level" language here is sort of pointless and "the comparative power" of C meaningless. It won't produce an advantage, it will just be more of a tedious pain.
Last edited by MK27; 07-15-2009 at 08:43 AM.
C programming resources:
GNU C Function and Macro Index -- glibc reference manual
The C Book -- nice online learner guide
Current ISO draft standard
CCAN -- new CPAN like open source library repository
3 (different) GNU debugger tutorials: #1 -- #2 -- #3
cpwiki -- our wiki on sourceforge
