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