Featured White Papers

• Java Web Hosting | DailyRazor.com - Over 10yrs Of Java Web Hosting Exp!

Sponsored Links

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Java Tip 41: POSTing via Java revisited

Learn how to display the HTML document returned by the Web server

By John D. Mitchell, JavaWorld.com, 10/01/97

Note: This tip assumes an understanding 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 results of a POST from an applet? Well, there are four answers to that question. In order of increasing pain, these are:

• We can't.
• Don't post.
• Use a bean.
• Cheat.

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 isn't small, it requires a browser supporting beans, and it isn't 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:

1. The applet POSTs information to the server just as before.
2. The server uses the POST information to generate HTML.
3. The server saves the HTML to a file on the Web server.
4. The server returns a magical key to the applet.
5. The applet encodes the key into a URL back to the server.
6. The applet instructs the browser to display a Web page by using the generated URL in a showDocument() call.
7. The server accepts the GET request and extracts the magic key parameter.
8. The server retrieves the file associated with the magic key.
9. The server returns the HTML contents from the file to the browser.
10. 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."