Ro 2004-11-05 (Nov 5th, 2004)
Lovingly crafted simplicity.
CGI can get complex when you include library after library, so let's do it by hand:
#!/usr/bin/tclsh puts "Content-type: text/plain\n" puts eogieogeig
The most basic cgi, all it does is display some text, not even html! But hey, if you're this far, your server is set up, your permissions on your cgi file are correct, and that's half the battle.
#!/usr/bin/tclsh puts "Content-type: text/html\n" puts { <html> <head> <title>wonderz</title> </head> <body> aloha! </body> </html> }
Great! You're sending them html now. Notice the Content-type header.
#!/usr/bin/tclsh puts "Content-type: text/plain\n" parray env
Wow! Text again, but this time we're dumping out our environment variables, and thats the guts of interfacing to the server, hence the term Common Gateway Interface.
GPS: Nice simple example. I'm not positive, but I seem to recall reading that \r\n is the standard EOL pattern for CGI apps. Thus I usually use puts "Content-type: text/plain\r" I've used \r\n for my CGI work with Roxen, without problems. Also, there are CGI-related packages in tcllib that are useful for translating the arguments from a web browser into a more usable format.
2007-01-02 gg - The official requirements are an output of "Content-Type: ...\r\n\r\n"
pepolez: I've used puts "Content type: text/html\n" without any problems. I am however curious as to how to allow a CGI script to output jpeg image data copied from a local file, so that the script outputs a jpeg image to the client browser.
AMG: The following works for me.
fconfigure stdout -translation crlf puts "Content-type: image/jpeg\n" fconfigure stdout -translation binary set chan [open whatever.jpg] fconfigure $chan -translation binary fcopy $chan stdout close $chan
Without the [fconfigure] invocations, the above does not work.
For added fun and enjoyment, dynamically generate the images. Check out GD or fly. Maybe you can cobble together a non-GUI Tk and use its image manipulation. There are all sorts of options here. You can even bind to the library of your choice with swig.
LES on 11-26-2006: I used that kind of approach to upgrade my Web site from PHP to Tcl two years ago, and have always had a tiny litle problem: the W3.org validator can't see any of my HTML [L1 ]. Apparently, regular browsers can see it fine [L2 ]. I've also tested my site with several browsers myself, including a Palm device and a cell phone. It's just the W3.org validator that can't see my HTML, but that didn't occur when I used PHP. I wonder what I could be doing wrong.
LV 2007 Jan 02 - LES, try adding that "\r\n\r\n" at the end of your Content-type and see if that helps any in convincing the validators to see your stuff.
LES on 2007 Jan 03: No, it doesn't. But thank you for the suggestion. The validation form has a "Show Source" option that tells me the validator just sees an empty page instead of HTML. Baffling, to say the least.
2007-01-03 gg - Look at the following (using netcat/nc):
www.braziliantranslation.net [64.71.173.72] 80 (http) open GET / HTTP/1.0 Host: www.braziliantranslation.net HTTP/1.1 200 OK Date: Wed, 03 Jan 2007 05:02:11 GMT Server: Apache/1.3.29 (Unix) mod_webkit/0.9.1 mod_perl/1.29 PHP/5.1.4 mod_ruby/1 .2.6 Ruby/1.8.5(2006-08-25) mod_ssl/2.8.16 OpenSSL/0.9.7j Connection: close Content-Type: text/html; charset=iso-8859-1 X-Pad: avoid browser bug sent 51, rcvd 285: NOTSOCK
Chad 2015 Nov 24: POST data can be grabbed "by hand" too:
if {$::env(REQUEST_METHOD) == "POST"} { gets stdin my_post_data }