CGI : Java Glossary

CGI (Common Gateway Interface). A non-Java technique of sending data from HTML (Hypertext Markup Language) 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 (Multipurpose Internet Mail Extensions). Java can simulate the form on the client side, or replace the C with servlets on the server side. 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.

recommend book⇒Core Web Programming, second edition

by:

Marty Hall and Gary Cornell

978-0-13-089793-0

paperback

publisher:

Prentice Hall

978-0-613-92274-6

hardcover

published:

2001-06-03

1250 pages. Also has some simple RMI examples. 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.

Greyed out stores probably do not have the item in stock

recommend book⇒Core Servlets and Javaserver Pages: Advanced Technologies, Vol. 2, second edition

by:

Marty Hall, Larry Brown, Yaakov Chaikin

978-0-13-148260-9

paperback

publisher:

Prentice Hall

B004YWAZFA

kindle

published:

2007-12-01

Complete text of the book available on line in pdf format.

Greyed out stores probably do not have the item in stock

recommend book⇒More Servlets and Java Server Pages

by:

Marty Hall

978-0-13-067614-6

paperback

publisher:

Pearson Education

published:

2001-12-26

Complete text of the book available on line in pdf format.

Greyed out stores probably do not have the item in stock

GET and POST are two ways to request information from a server. In GET all the request information is contained tacked onto the URL (Uniform Resource Locator) (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) to the server 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 (Microsoft Internet Explorer) 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 is 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
CGI spec
cookie
echo server
File I/O Amanuensis has sample code to do CGI in Java in the client
HTML Forms
HTTP
HTTP Client
MIME
remote file access
screen scraping
servlet
sniffer
URLConnection
W3C
Webbug

	You can get the freshest copy of this page from:	or possibly from your local J: drive (Java virtual drive/mindprod.com website mirror)
	http://mindprod.com/jgloss/cgi.html	J:\mindprod\jgloss\cgi.html
	Please email your feedback for publication, letters to the editor, errors, omissions, typos, formatting errors, ambiguities, unclear wording, broken/redirected link reports, suggestions to improve this page or comments to Roedy Green : . If you want your message, your name or email kept confidential, not considered for public posting, please explicitly specify that. Unless you state otherwise, I will treat your message as a letter to the editor that I may or may not publish in the feedback section. After that, it will be too late to retract it. If you disagree with something I said, please quote it and cite the web page where you found it, tell me why you think it is wrong, and, if possible, provide some supporting evidence. Threatening to kill me or spouting obscenities has yet to persuade me to change my mind.
	Canadian Mind Products
	mindprod.com IP:[65.110.21.43]
view Blog	Your face IP:[38.107.179.214]
Feedback	You are visitor number 20,216.