Posting Via Java Revisited

Summary

In

JavaWorld's August issue, we ran a Java Tip on "POSTing from applets." Not only was the tip popular with readers, but it spawned a number of questions. This new tip on POSTing via Java attempts to satisfy your curiosity. We show you how TO Send Post Requests to Web Servers and Display The Response In an applet.

(2,000 Words)

BY

John D. Mitchell

hew! Our previous tip on POSTing from applets generated a slew of reader questions. The predominant question was "How do I display the HTML document returned by the POST CGI-bin handler on the Web server?". In this tip, we explore the Answers to That Question and Delve Into Some Cool Server-Side Java Issues.

Note: this Tip Assumes An Undering On The Part of The Reader of The Basic Problems and Issues of Posting Via Java. If You're Not Familiar with these Concepts, Refer to Java Tip 34.

SO, Just How Do We Display THE RESUS OF A Post from an applet? Well, There Are Four Answers To That Question. In Order of Increasing Pain, Thase Are:

We can't. Don n't post...............

As discussed in Java Tip 34, the current browser security managers will not allow an applet to display applet-generated HTML in a browser; the browser only lets us point it toward URLs that it will display on our behalf This situation is just so unsatisfying. !

We can side-step the POST results display restriction by - surprise -! Not using POST Instead, we can encode some information in the URL that we provide to the showDocument () method That information will get passed on to the the.. Web server as parameters to the GET request Unfortunately, this does have some drawbacks:. Only limited amounts of data can be transferred - plus, the URL is munged in the process So it's pretty ugly We'll see an example of how.. to code this a bit later.Just recently, Sun's JavaSoft division released an HTML renderer bean. (There are a couple of other commercial offerings.) So, it's possible to use the bean as part of your applet and have it display the pages. What are the drawbacks? Size, compatibility, and cost. The bean certainly is not small, it requires a browser supporting beans, and it is not free. Of course, we could all spend time writing our own rendering component, but that's Silly.

The fun and productive solution to the problem is to cheat In this particular case, we cheat by requiring the collusion of the server-side code (for example, the CGI-bin script) with our applet The basic idea is simple:.. Combine The use of post with a subsequent get. The process is as follows:

The applet POSTs information to the server just as before. The server uses the POST information to generate HTML. The server saves the HTML to a file on the Web server. The server returns a magical key to the applet. The applet encodes the key into a URL back to the server. The applet instructs the browser to display a Web page by using the generated URL in a showDocument () call. The server accepts the GET request and extracts the magic key parameter. The server retrieves the file associated with the magic key. The server returns the HTML contents from the file to the browser. The browser displays the HTML contents.This back-and-forth process is definitely more complicated than the other solutions, but it works today across a wide combination of clients and servers. The drawbacks to this process stem from needing to perform multiple HTTP requests to fulfill a single, complete transaction. We must retain "state" information across the multiple requests to be able to keep track of what's going on (recall that HTTP is a stateless request / response protocol) Robustly managing the requisite state information can be quite challenging As John Ousterhout, the father of the Tcl scripting language and the Sprite distributed operating system, has said:.. "State is The Second Worst Thing in Distributed Computing. No, State Is The Worst.

The server part is the most complicated piece, so let's look at the applet first. There are only a few differences between this applet and the Happy applet in the previous Java Tip 34. POSTing to the server is identical, but we have to modify the Reading of the response from the server:

input = new DataInputStream (urlConn.getInputStream ()); String str = null; String firstLine = null; (! null = ((str = input.readLine ()))) while {if (null == firstLine) firstLine = str System.out.Println (STR); TextArea.AppendText (Str "/ N");} Input.close (); by Fiat, The Server Returns A Magic Key As The First Line. The Magic Key Is The Piece of state information that is used to uniquely identify which transaction the applet is involved in with this server. If there are any problems in processing the POST request, the server notifies the applet that this is the case by returning the string "nil" followed by a TEXTUAL DESCRIPTION OF THE PROBLEM. The Only Thing The applet Needs to do now is build the url and call showdocument () to display the html:

IF (NULL! = firstline) {url = new url ("http: //" ). gethost ()). TOSTRING () "/ poster?" firstline); (getAppletContext ()) .Showdocument (URL, "_blank");}

Be sure to note that the URL parameter must be URL-encoded. In that snippet, we only have to add the question mark to separate the base URL from the passed parameters, since the magic key from the server is already safely encoded.

Now that we have the applet part taken care of, let's dive into the server. The server-side code in the earlier Java Tip on POSTing was a traditional CGI-bin script written in Perl. Perl is a fine solution, but would not you rather write server-side Java We can write CGI-bin scripts in Java (see the Resources section), but there's a much better solution:?. Java that is run as part of the Web server itself This type of server-side Java is known as a servlet The solution we're presenting here will be a servlet written to the Java Servlet API -. although you can implement the same solution using CGI-bin scripts in Perl, Tcl, Java, or whatever.Note that an Introduction to servlet programing and administration is beyond the scope of this article; we'l be covering Only to the posting solution.

The PosterServlet code contains a fair number of comments to guide your walk-through. There's lots of error handling and extra checking to handle the plethora of possible problems, some denial-of-service attacks, and so on, but mostly you can ignore that Stuff. (We'll Discuss Security Issues in More Depth Later) The servlet is written to the java 1.1.x Apis (Whereas the applet code is java 1.0.2 code).

The doPost () method handles the POST request - that is, it takes care of the first three server responsibilities: It generates an HTML document based on the POSTed information, saves the document to a temporary disk file, and returns a magic key to The applet what identifier the html document and is suitable for directly Embedding Into a subsequent get request.

. Here's the core of the code (. See the actual source file for the complete code) Implementation note: The magic key actually is the name of the file that generated the HTML document for that transaction The name is generated using the java.util. .Random class to generate a long value.

protected void doPost (HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {response.setContentType ( "text / plain"); // Build the output filename.String fileName = (new Long (randomizer.nextLong ())) toString (. ); File file = null; try {file = new File (posterTempDir File.separator fileName posterTempExt);} catch (Exception e) {sendPostFailure (response, "Unable to build output file path!"); return;} // Open the output file.PrintWriter output = null; try {output = new PrintWriter (new BufferedWriter (new FileWriter (file)));} catch (IOException e) {sendPostFailure (response, "Unable to open output file!") }} Output.println (""); Output.print ("