ch12.htm

JAVA Developing Professional JavaApplets

the HTTP server. Remember how the server sent everything as <TT>Content-type:
text/html</TT>? This was a MIME content type. Servers are
configured to send each file format with a specific MIME type.
Typically, this is done by tying the suffix of a file to a specific
content type. Table 12.1 lists some common file extensions and
their MIME content types.
<P>
When HotJava sees a MIME content type, it tries to load the appropriate
handler. Again, if it can't find a local handler, it will ask
the remote server for one.<BR>
<P>
<CENTER><B>Table 12.1. Common file extensions and their MIME content
types.</B></CENTER>
<P><CENTER><TABLE BORDERCOLOR=#000000 BORDER=1 WIDTH=80%>
<TR VALIGN=TOP><TD WIDTH=133><I>File Extension</I></TD><TD WIDTH=198><I>MIME Content Type</I>
</TD></TR>
<TR VALIGN=TOP><TD WIDTH=133><TT>html</TT></TD>
<TD WIDTH=198>text/html</TD></TR>
<TR VALIGN=TOP><TD WIDTH=133><TT>htm</TT></TD>
<TD WIDTH=198>text/html</TD></TR>
<TR VALIGN=TOP><TD WIDTH=133><TT>txt</TT></TD>
<TD WIDTH=198>text/plain</TD></TR>
<TR VALIGN=TOP><TD WIDTH=133><TT>rtf</TT></TD>
<TD WIDTH=198>text/rtf</TD></TR>
<TR VALIGN=TOP><TD WIDTH=133><TT>ps</TT></TD>
<TD WIDTH=198>text/postscript</TD></TR>
<TR VALIGN=TOP><TD WIDTH=133><TT>doc</TT></TD>
<TD WIDTH=198>text/msword</TD></TR>
<TR VALIGN=TOP><TD WIDTH=133><TT>gif</TT></TD>
<TD WIDTH=198>image/gif</TD></TR>
<TR VALIGN=TOP><TD WIDTH=133><TT>jpg</TT></TD>
<TD WIDTH=198>image/jpeg</TD></TR>
<TR VALIGN=TOP><TD WIDTH=133><TT>mpg</TT></TD>
<TD WIDTH=198>video/mpeg</TD></TR>
<TR VALIGN=TOP><TD WIDTH=133><TT>wav</TT></TD>
<TD WIDTH=198>audio/wav</TD></TR>
<TR VALIGN=TOP><TD WIDTH=133><TT>au</TT></TD>
<TD WIDTH=198>audio/ulaw</TD></TR>
<TR VALIGN=TOP><TD WIDTH=133><TT>tar</TT></TD>
<TD WIDTH=198>file/tar</TD></TR>
<TR VALIGN=TOP><TD WIDTH=133><TT>arc</TT></TD>
<TD WIDTH=198>file/arc</TD></TR>
<TR VALIGN=TOP><TD WIDTH=133><TT>lha</TT></TD>
<TD WIDTH=198>file/lharc</TD></TR>
<TR VALIGN=TOP><TD WIDTH=133><TT>zip</TT></TD>
<TD WIDTH=198>file/zip</TD></TR>
</TABLE></CENTER>
<P>
<P>
Netscape attempts to mimic this behavior with &quot;plug-ins.&quot;
You can configure Netscape Navigator to run plug-in programs when
it encounters certain MIME content types. The one thing that Netscape
can't do is use the server to load one on the fly. Even if it
could, there are so many different platforms available, who knows
if it would load the correct executable for your specific architecture.
Java is portable, so you can compile it once and execute it everywhere
there's an interpreter present. If you're using the HotJava browser,
then you have a running Java interpreter already in action.
<H3><A NAME="SecurityModel">Security Model</A></H3>
<P>
HotJava has a much more flexible security model than Netscape
Navigator. Instead of banning all file access and limiting socket
access, HotJava allows the severity of restrictions to be configured.
<P>
Network security has four modes:
<UL>
<LI><B>No access</B>-Applets cannot open any external URLs or
socket connections.
<LI><B>Applet host</B>-Applets can open sockets only to the host
they were loaded from.
<LI><B>Firewall</B>-Applets can open sockets to the host they
were loaded from and to hosts within a configurable list or domain.
<LI><B>Unrestricted</B>-Applets can open sockets to anywhere.
</UL>
<P>
In addition, you can also apply these modes to applet loading:
<UL>
<LI><B>No access</B>-No Java applets can be loaded.
<LI><B>Applet host</B>-Only applets from the local file system
can be loaded.
<LI><B>Firewall</B>-Applets from hosts within a firewall can be
loaded.
<LI><B>Unrestricted</B>-Applets can be loaded from any host.
</UL>
<P>
Accessing local file storage is also a configurable option. HotJava
uses two environment variables to control file access by applets:
<UL>
<LI><TT>HOTJAVA_READ_PATH</TT>
<LI><TT>HOTJAVA_WRITE_PATH</TT>
</UL>
<P>
Both these variables consist of a semicolon-separated list of
directories. Applets can access any files in these directories
or their subdirectories.
<H4>Firewall Security Model</H4>
<P>
The <I>firewall security model</I> is a powerful option. The corporate
world is only now becoming aware of the vast power inherent in
HTML. Corporate intranets are sprouting up everywhere; these corporate
nets offer full access for machines behind their firewall, but
limited or no access to the Internet at large. Allowing a browser
to have full access rights within a firewall offers the necessary
flexibility that corporations demand. The current Netscape security
model is too restrictive for business use. Real-world applications
need local storage and flexible connectivity options to be of
any use. Browsers will probably adopt this firewall model as business
demands for Java grow.
<H3><A NAME="Alpha3DistributionDifferences">Alpha3 Distribution
Differences</A></H3>
<P>
Unfortunately, HotJava is mired in the world of Java Alpha3. It
can't run applets written for version 1.0, but it still has instructive
use. The Java language is quite stable, so you'll find no differences
in the language syntax or semantics, but there are some major
differences in the class packages and libraries.
<P>
To begin with, there is no classes.zip file. All the Java classes
are contained in a directory tree that reflects the package name
of each class. Actually, if you peered inside the zipped class
file from version 1.0, you would find that this same tree has
been maintained in the compressed image. Figure 12.1 shows the
major packages within the directory hierarchy.
<P>
<A HREF="f12-1.gif" ><B>Figure 12.1 : </B><I>Directory structory and major packages.</I></A>
<P>
This layout should look familiar to you, with the exception of
the browser package. This package contains classes and interfaces
to HotJava's general functionality. In particular, the Applet
class is located within the browser package.
<P>
The protocol and content handler classes are under the following
directories:
<BLOCKQUOTE>
<TT>classes/net/www/protocol<BR>
classes/net/www/content</TT>
</BLOCKQUOTE>
<P>
When HotJava makes a request to a server for a specific handler,
it uses the same path as the local directories. For example, if
you encounter MIME type <TT>text/plain</TT>
and there's no plain.class within the local text subdirectory,
HotJava issues the following request:
<BLOCKQUOTE>
<TT>GET /classes/net/www/content/text/plain.class
HTTP/1.0</TT>
</BLOCKQUOTE>
<P>
Unfortunately, this request issued to the previous chapter's HTTP
server would go unanswered because HotJava is waiting for a socket
close notification that will never arrive due to a bug in the
JDK. It seems as though <TT>socket.close()</TT>
doesn't work under either Windows 95 or Windows NT. You need to
change HotJava's source code to use the <TT>Content-length</TT>
MIME parameter that the HTTP server dutifully places into the
outbound stream.
<H2><A NAME="AlteringtheHotJavaSource"><FONT SIZE=5 COLOR=#FF0000>Altering
the HotJava Source</FONT></A></H2>
<P>
To alter the HotJava source, you must first have a thorough understanding
of the inner workings of the HotJava protocol handler; its principle
function is to provide the input stream:
<BLOCKQUOTE>
<TT>public InputStream openStream(URL u);</TT>
</BLOCKQUOTE>
<P>
The handler for HTTP constructs an instance of the HttpClient
class to perform its low-level work; this class extends NetworkClient.
Then the socket connection is opened and the request is sent.
The input stream is acquired and wrapped in a BufferedInputStream.
The HttpClient parses the response header and stores the results.
<P>
At this point, the constructor for HttpClient returns. The HTTP
protocol handler now processes the response. If the MIME header
contains a valid <TT>Content-length:</TT>
field, the input stream is further encapsulated in a MeteredStream.
The Stream class MeteredStream is the perfect place to make the
alterations.
<H3><A NAME="BufferedStreamsPrimer">Buffered Streams Primer</A>
</H3>
<P>
The standard input stream hierarchy looks like this:
<BLOCKQUOTE>
<TT>InputStream<BR>
&nbsp;&nbsp;&nbsp;&nbsp;FilterInputStream<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;BufferedInputStream</TT>
</BLOCKQUOTE>
<P>
The following list shows the public methods of the FilterInputStream
class:<BR>
<P><CENTER><TABLE BORDERCOLOR=#000000 BORDER=1 WIDTH=80%>
<TR VALIGN=TOP><TD WIDTH=373><I>FilterInputStream Members</I></TD></TR>
<TR VALIGN=TOP><TD WIDTH=373>
<BLOCKQUOTE>
<TT>available()<BR>
close()<BR>
mark(int)<BR>
markSupported()<BR>
read()<BR>
read(byte[])<BR>
read(byte[], int, int)<BR>
reset()<BR>
skip(int)</TT>
</BLOCKQUOTE>

</TD></TR>
</TABLE></CENTER>
<P>
<P>
This class is extended by BufferedInputStream. Buffered streams
offer a look-ahead buffer that enables a stream to be read in
large chunks, but processed a character at a time. They also provide
mark/reset capability. Frequently, applications will need to parse
a stream, looking for a specific string. If this string is not
found, then the application should reset the stream so other processes
can try to parse the same data. Marking a stream tells the BufferedInputStream
object to remember the current location within the buffer. If
a subsequent reset is called, the object will march backward in
its buffer to the previously stored location. New read requests
will be satisfied from the old location. The following list shows
the public methods of the BufferedInputStream class; all these
methods override the equivalent named method in the FilterInputStream
class:<BR>
<P><CENTER><TABLE BORDERCOLOR=#000000 BORDER=1 WIDTH=80%>
<TR VALIGN=TOP><TD WIDTH=404><I>Public Methods of BufferedInputStream</I>
</TD></TR>
<TR VALIGN=TOP><TD WIDTH=404>
<BLOCKQUOTE>
<TT>available()<BR>
mark(int)<BR>
markSupported()<BR>
read()<BR>
read(byte[], int, int)<BR>
reset()<BR>
skip(int)</TT>
</BLOCKQUOTE>

</TD></TR>
</TABLE></CENTER>
<P>
<P>
Start with the following InputStream:
<BLOCKQUOTE>
<TT>&quot;BufferedInputStreams are handy!&quot;</TT>
</BLOCKQUOTE>
<P>
Next, execute the following code snippet on the stream:
<BLOCKQUOTE>
<TT>byte data[] = new byte[13];<BR>
is.read(data);&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // read 13
characters [BufferedInput]<BR>
mark(200);&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;//
save this position for up to 200 characters<BR>
is.read(data, 0, 7);&nbsp;&nbsp;// read 7 more characters [Streams]
<BR>
reset();&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;//
go back<BR>
byte rest[] = new byte[18];<BR>
is.read(rest);&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // read 18
more characters [Streams are handy!]</TT>
</BLOCKQUOTE>
<P>
A MeteredStream extends FilterInputStream; you can find its source
code in the HotJava directory:
<BLOCKQUOTE>
<TT>classsrc\net\www\html\MeteredStream.java</TT>
</BLOCKQUOTE>
<H4>Metered Stream and HTTP</H4>
<P>
HotJava has a progress display, performed by the MeteredStream
class, that can show how a transfer is progressing. Whenever the
HTTP protocol handler detects a length parameter in the response
header, it will encapsulate the current input stream within a
MeteredStream:
<BLOCKQUOTE>
<TT>String ct = http.getHeaderField(&quot;content-length&quot;);
<BR>
int len = 0;<BR>
if (ct != null &amp;&amp; (len = Integer.parseInt(ct)) != 0) {
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;is = new MeteredStream(is, len, url);</TT>
</BLOCKQUOTE>
<P>
Since all subsequent reads will be done through the MeteredStream
class, this is the ideal location for the changes.
<H3><A NAME="MakingtheChanges">Making the Changes</A></H3>
<P>
Now you simply need to make stream reads return end-of-stream
once the length parameter has been read. The following list shows
the overriding methods in the MeteredStream class:<BR>
<P><CENTER><TABLE BORDERCOLOR=#000000 BORDER=1 WIDTH=80%>
<TR VALIGN=TOP><TD WIDTH=427><I>MeteredStream Public Methods</I></TD></TR>
<TR VALIGN=TOP><TD WIDTH=427>
<BLOCKQUOTE>
<TT>read()<BR>
read(byte[], int, int)<BR>
skip(int)<BR>
close()</TT>
</BLOCKQUOTE>

</TD></TR>
</TABLE></CENTER>
<P>