Java Glossary : CGI

Last updated 2004-06-28 by Roedy Green ©1996-2004 Canadian Mind Products

Java definitions: 0-9 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

You are here : home : Java Glossary : C words : CGI.

CGI

Common Gateway Interface. A non-Java technique of sending data from HTML forms in browsers to server programs written in C, Python, Tcl or Perl. They typically do data base searches or process the data in HTML forms and send back MIME. Java can simulate the form on the client side, or replace the C with servlets on the server side. Common Gateway Interface RFC Project has a CGI spec. It is written in typical academic official spec style. It is intentionally made abstract, vague, and incomprehensible to prove how brilliant the authors are that no one but they can make head nor tail of what it means. Like a typical spec it uses a secret notation instead of examples. However, if you need the language lawyer type details that's the place to go. I am snarly because I have wasted hours trying to get some very simple questions answered about CGI. That spec is not that much worse than your average language reference document. There are hundreds of tutorials, but focus on using Perl write server code with no real understanding of how it all works. I found one great tutorial suite that explains what is really going on, which is much more helpful for Java or C programmers at The Complete Webmaster.

	Core Web Programming, Second Edition
	0-13-089793-0
	Marty Hall and Gary Cornell
1250 pages. This is a great doorstop of a book. It has a few chapters on client-server programming in Java, and a section of that is on CGI. I have looked at hundreds of Java books and found nothing that deals in depth with client side Java talking to CGI, except Marty's book. It is really very simple and he does an excellent job of explaining it. Marty has posted all the source code examples from the book for anyone to use. These contain updates and errata fixes you don't get on the CD-ROM that comes with the book.

	Core Servlets and Java Server Pages
	0-13-089340-4
	Marty Hall
Complete text of the book available on line in pdf format.

	Core Servlets and Java Server Pages
	0-13-067614-4
	Marty Hall
Complete text of the book available on line in pdf format.

GET and POST are two ways to request information from a server. In GET all the request information is contained tacked onto the URL (which can thus be made part of a bookmark). In PUT it is contained in a separate trailing message. GET is idempotent, a mathematician's word meaning "gives identical results with identical input and has no side effects". Thus if you do a second identical GET, the results can be fished out of cache, without reprocessing the request. In contrast, a POST is assumed to have side effects, or to produce different results each time it is invoked. It has some lasting effect on the world, e.g. submitting a membership application. The request has to be reprocessed from scratch.

The Cyberspyder people make a free tool to help you understand what browsers and servers send back and forth to each other called Webbug. It lets you compose GET commands and see the results. Unfortunately, it does not let you snoop on what browsers and servers are sending to each other.

Forms

When you fill in a form and hit submit, a message sent from your browser (or program simulating a browser) looks like this:

POST actionscript HTTP/1.0
Referer: http://mindprod.com/test.html
Content-type: application/x-www-form-urlencoded
Accept: */*
User-Agent: Mozilla/2.0 (compatible; MSIE 3.01; Windows 95)
Content-Length: 1234

date=03%2F05%2F26&date_fmt=yymmdd

• The actionscript comes from the <form method="POST" action="actionscript"> It it the name of the program that will handle the request on the server.
• The referrer is the URL of the page containing the form.
• The Content-Length is the length in bytes of the parm=value list following the blank line.
• The data are encoded as parm=value&parm=value. The parm names and values are url-encoded with java.util.net.URLEncoder.encode, which converts spaces to +, and special characters to %xx where xx is the hex equivalent. Note that even POST can't send raw binary data. It must be URL encoded. The = and & are not URL encoded, just the parameter names and their values.
• The submit button has a hidden name and value as well so the server can tell which submit button was pressed.
• Multiple select fields (where you are allowed to select any combination of choices) are sent like this &Currency=CAD&Currency=USD&Currency=EUR

You can send such a message at the low level with Socket.getOutputStream() and read the respond with Socket.getInputStream(), or more commonly at a higher level with HttpURLConnection. See the file I/O amanuensis for details.

When you use the GET protcol the parameters are tacked on the end of the URL, separated-by a ?.

Beware of using raw Sockets for get and put for long messages. Responses come in blocks with a length field on the front. You have to bypass these. They will show up as something like 2000 cr lf in the middle of your data.

POST and GET are not efficient ways for transmitting large volumes of binary data. For that you would set up a separate socket connection.

Bignose Bird has some CGI scripts in Perl you can cannibalise. It also has some tutorials that introduce you to Perl. The File I/O Amanuensis has sample code to do CGI in the client. Check out HTTP and MIME ¤ cookie ¤ echo server ¤ HTTP Client ¤ remote file access and servlet ¤ W3C ¤ Webbug

home	Canadian Mind Products
	mindprod.com IP:[24.87.56.253]
	Your IP:[80.134.30.163]
	You are visitor number 1407.
	Please send errors, omissions and suggestions
	to improve this page to Roedy Green.
	You can get a fresh copy of this page from:	or possibly from your local J: drive mirror:
	http://mindprod.com/jgloss/cgi.html	J:\mindprod\jgloss\cgi.html