Java Servlet Programming
by Jason Hunter with William Crawford
Here are the changes made in the 7/99 reprint:
(30) The footnote at the bottom of the page, 2nd line, used to read:
...generate output for a servlets used ...
It now reads:
...generate output for a servlet used ...
{85} Near the bottom is the code fragment:
String[] words = req.getParameterValues("word");
if (words != null)
{
for (int i = 0; i < words.length; i++)
{
String definition = getDefinition(words[i]);
out.println(word + ": " + definition); // BUG
out.println("
");
}
}
the line with //BUG has been changed from "word" to "words[i]".
{95} In the footnote, changed:
http://ds.internic.net/rfc/rfc1630.txt
To:
http://www.ietf.org/rfc/rfc1630.txt
(104) 8th line from the bottom, changed:
... stream, you should to use getReader()
to:
... stream, you should use getReader()
{107} 2nd paragraph in "Receiving files using the input stream," changed:
http://ds.internic.net/rfc/rfc1867.txt
To:
http://www.ietf.org/rfc/rfc1867.txt
(110) Line 13 from bottom, changed:
... request, a directory to saves files to, ...
to
... request, a directory to save files to, ...
{202} End of 2nd paragraph of "Persistent Cookies," changed:
http://ds.internic.net/rfc/rfc2109.txt
To:
http://www.ietf.org/rfc/rfc2109.txt
{225} In the paragraph before example 8-2, changed:
http://ds.internic.net/rfc/rfc1521.txt
To:
http://www.ietf.org/rfc/rfc1521.txt
(232-233) Starting with the paragraph that starts "Public
key encryption schemes have been around...", removed that
paragraph and the three that followed it and replaced them
with the following five paragraphs:
-----
Public key encryption schemes have been around for several years and
are quite well developed. Most are based on the patented RSA algorithm
developed by Ron Rivest, Adi Shamir, and Leonard Adelman. RSA uses
very large prime numbers to generate a pair of asymmetric keys (i.e.,
each key can decode messages encoded with the other). Individual keys
come in varying lengths, usually expressed in terms of the number of
bits that make up the key. 1024- or 2048-bit keys are adequate for
secure RSA communications.
Because keys are so large, it is not practical for a user to type one
into her web browser for each request. Instead, keys are stored on
disk in the form of digital certificates. Digital certificates can be
generated by software like Phil Zimmerman's PGP package, or they
can be issued by a third party. The certificate files themselves can
be loaded by most security-aware applications, such as servers,
browsers, and email software.
Public key cryptography solves the confidentiality problem because the
communication is encrypted. It also solves the integrity problem: Will
knows that the message he received was not tampered with since it
decodes properly. So far, though, it does not provide any
authentication. Will has no idea whether Jason actually sent the
message. This is where digital signatures come into play. Because
public and private keys are asymmetric, Jason can first use his
private key to encode a message and then use Will's public key to
encode it again. When Will gets the message, he decodes it first with
his private key, and then with Jason's public key. Because only
Jason can encode messages with his private key--messages that can be
decoded only with his public key--Will knows that the message was
truly sent by Jason.
This is different from simpler symmetric key systems, where a single
key is used for encoding and decoding. While asymmetric keys have the
significant advantage of allowing secure communication without ever
requiring a secure channel, they have the disadvantage of requiring
much more computational muscle. As a compromise, many encryption
systems use asymmetric public and private keys to identify each other
and then confidentially exchange a separate symmetric key for
encrypting the actual exchange. The symmetric key is usually based on
DES (Data Encryption Standard).
U.S. government restrictions currently limit symmetric key size to 56
bits (about 72 quadrillion possible keys). Messages encrypted with a
56-bit key are difficult to decode, but by no means impossible--large
networks have been used to decode such messages within a matter of
days. With the United States, however, many systems use 128-bit DES
keys (about 3.40282 x 10^38 possible keys). Because there is no known
way to decode a DES-encrypted message short of brute-force trial and
error, messages sent using large keys are very, very secure.
{234} End of 1st paragraph of "Secure Sockets Layer (SSL)," changed:
http://www.consensus.com/ietf-tls
To:
http://www.ietf.org/rfc/rfc2246.txt
(234) 5th item in list: changed "asymmetric" to "symmetric" twice
in this list item.
(238) 1st paragraph after itemized list: in "None of these
approaches works very well" changed "works" to "work"
(239) Last paragraph before "Fine-grained control," changed "can be
signed using digital certificates." to "can be digitally signed."
{372} In the footnote, changed:
http://ds.internic.net/rfc/rfc2278.txt
To:
http://www.ietf.org/rfc/rfc2278.txt
{376} 1st paragraph of "UCS-2 and UTF-8," changed:
http://ds.internic.net/rfc/rfc2279.txt
To:
http://www.ietf.org/rfc/rfc2279.txt
(377) 1.1 used to read
Chinese, Korean, Russian, and Hebrew.
Now reads:
Chinese, Korean, and Russian.
{389} In the footnote, changed:
http://ds.internic.net/rfc/rfc2070.txt
To:
http://www.ietf.org/rfc/rfc2070.txt
{402} In the 5th list item, changed:
http://ds.internic.net/rfc/rfc822.txt
To:
http://www.ietf.org/rfc/rfc822.txt
{442} In the "Description," changed:
http://ds.internic.net/rfc/rfc2045.txt
To:
http://www.ietf.org/rfc/rfc2045.txt
{454} In the description for "doPut()" changed:
http://ds.internic.net/rfc/rfc2068.txt
To:
http://www.ietf.org/rfc/rfc2068.txt
{472} In the paragraph before table C-2 changed:
http://ds.internic.net/rfc/rfc2068.txt
To:
http://www.ietf.org/rfc/rfc2068.txt