This document has the following sections:

• Bugs Fixed In This Release
• Supported Environments
• Important JavaServer Topics
• Changes to the Servlet API
• If You Are Locked Out of The JavaServer
• Additional Documentation

Bug 4058110	Fix for admin applet problems under win95. The admin applet now uses GET instead of POST.
Bug 4058345	Authentication is bypassed when URL has double slash and a trailing slash.
Bug 4058867	ServerSideInclude is now fully threadsafe.
Bug 4058868	HEAD will now log 0 bytes to access log for static files as previously it gate the incorrect size of the file.
Bug 4058985	Modify srcdemos to use javax.servlet.
Bug 4059892	Custom classloaders don't function correctly.
Bug 4059897	POST operations combined with keepalive will no longer throw spurious Invalid Request exceptions.
Bug 4063766	Files are deleted when setting proxy disk cache location to the root directory.
Bug 4064232	Cannot load certificates issues by Verisign certificates.
Bug 4065650	The httpd.nojre.sh scripts sets the classpath to classes.zip rather than classes.jar.

Supported Environments

To use JavaServer, you need a server environment (to run the server itself) as well as a client environment (from which to run administrative tools).

Server Environment

To run the server, you need a Java runtime environment that conforms with the JDK 1.1 (or above) FCS interfaces in order to run JavaServer. For many platforms, you can download a version from java.sun.com.

Note that on UNIX, you will probably want some special support to automatically run JavaServer as the default web server, and to run it as some user other than "root". At this time, we provide this support only for Solaris SPARC platforms. However, we do provide Posix-compatible sources for the native code needed to provide this functionality on other UNIXes. For more information, see The Installation Guide.

Note: JavaServer is only currently supported on platforms that have JDK 1.1 (and above) support. For up to date information on whether your target platform supports JDK 1.1, please contact the platform's vendor. The JavaServer team does not have this information.

Client Environment

The Administration Tool may not work on all web browsers. It depends on the browser being JDK 1.0.2 compatible (which most browsers are).

Current versions of Netscape Navigator (3.0), Microsoft Internet Explorer (3.0), and 1.0.2 AppletViewer are known to work. You may not be able to to administer JavaServer if you use older web browsers.

Important JavaServer Topics

To avoid this confusion, do not create usernames with spaces. Or if you have already done so, type underscore characters in the places where the spaces would be.

Using Restart Under Windows NT Stops System Service

If you stop the system service this way, you must restart it from the NT Services screen.

1. Double-click on the Services icon in the Settings/Control Panel.
2. On the Services dialog, select the JavaServer service.
3. Click Start.

so that the ssl.need-clnt-auth flag is set to true rather than false.

In this release, only SSL client certificates created by VeriSign(TM), Inc. will be accepted. (This bug will be fixed later.)

Note: For users running the HTTPS ("secure web") service, and who have gotten a certificate from VeriSign, Inc. or some other Certificate Authority, to upgrade from JavaServer Beta to 1.0 FCS (this release), you need to make a copy of the HTTPD_HOME/admin/keys file. Then when you reinstall the FCS copy, save that file in a different location: HTTPD_HOME/keys.

JavaServer and The JDBC-ODBC Bridge

There are many reasons for this. The two most compelling are:

• ODBC drivers are often not written to be re-entrant. Thus, they are not threadsafe.
• When native code crashes, it can (and will) take the whole Java Virtual Machine with it. (This is, in many ways, similar to what happens when the Unix kernel panics on a faulty device driver.)

To assure proper operation, do not nest CGI scripts in sub-directories below the directory you have set up as a substitute for cgi-bin. That is, do not try and set up your system so that your cgi scripts are in the directory

Note: The JavaServer package names have been changed. The new package names are: javax.servlet and javax.servlet.http.

Compatible Changes

• There is a new HttpUtils.parsePostData method, usable to parse POST bodies which are FORM encoded data.

  Several customers had noted the desirability of this feature.

• There is a new HttpUtils.getRequestURL method, which returns a string buffer containing a URL equivalent to that used by the client to issue the request (less query parameters).

  This functionality is used in a variety of places, particularly in larger systems, and is now packaged as a library routine so it doesn't need to be written and debugged each time.

• GenericServlet declares that it implements ServletContext, as it always did but without declaring that fact.

  This clarifies exactly what this class is doing.

• There's a new UnavailableException exception, which you should throw when your servlet becomes unavailable. For example, if you can't initialize, this is the error to throw.

  Previously, it was unclear how to handle initialization errors or how to make a server stop calling into a servlet that can't actually perform requests (e.g. because its data is corrupt).

• The HttpServlet class now provides much more value. Rather than overriding the service() method, you can instead override the doGet() method (for servlets supporting GET and HEAD) and/or the doPost() method (for servlets supporting POST). If you support GET and also override the getLastModified() method, you will automatically support HTTP/1.0 cache update protocols.

  This promotes strict HTTP 1.0 protocol compliance while making it practical to write HTTP oriented servlets without referring to the protocol specification.

• When requests comes in over HTTPS, three request attributes are accessible using the ServletRequest.getAttribute method:
  • javax.net.ssl.cipher_suite, the string name of the SSL cipher suite in use.
  • javax.net.ssl.peer_certificates, an array of X509 certificates which authenticates the client. This is only available when SSL client authentication is used.
  • javax.net.ssl.session, an SSL session object.

  These attributes are needed by HTTPS-aware applications.

• HttpServlet.init(), with no arguments, is gone. If you were using this call, you need to use the init(ServletContext) call instead, and call the superclass's method.

  This is an API simplification; having two methods doing almost the same thing was very confusing.

• Some of the interfaces have had new methods added. These will NOT affect you if you were subclassing the existing classes, rather than implementing those interfaces ... so for most purposes, these are compatible changes.
  • ServletRequest.getScheme() returns the URL scheme being used.

    For example, it tells whether you are coming in via HTTP or via HTTPS. Previously, there was no way to know this.

  • ServletRequest.getParameterValues() returns parameters which have multiple values, such as some kinds of HTML FORM parameters. Previously, getParameterValue returned a comma-separated list.

    This allows you to have multivalued parameters, where some of the values include commas. It also removes the need to parse values to remove those commas.

  • HttpServletResponse.containsHeader() allows you to test whether a header field has been defined already.

    This supports header fields which have multiple values.

• Servlet API reference documentation has been generally improved.

• You SHOULD set the content length on your servlet responses unless you are willing to tolerate performance penalties associated with not using HTTP "connection keep-alive".

• You MUST set all HTTP response headers before writing response data, since the headers can be flushed at any time after data starts to be written.

If, by chance, you do find yourself locked out of the JavaServer because of the assignment of access controls to any of the core internal servlets, you can recover from this situation quite easily by editing the acl.properties file for the service in which you have assigned the access controls.

To Edit The acl.properties File:

1. Change directory to
   server_root/properties/server/javawebserver/service_name

2. Open the file acl.properties in your favorite editor.
3. Look for the line that contains the name of the servlet, realm, and Access Control List in which the access controls were assigned, and either comment out the line or delete it from the file. For example, if you have set access controls on the admin servlet in the realm defaultRealm using the Access Control defaultAcl, the line would look like this:
   Servlet.admin=Basic:defaultRealm:defaultAcl

4. Stop the JavaServer processes. For more information, see Stopping the JavaServer.
5. Kill your browser and restart it.
6. Restart your JavaServer. For more information see Starting the JavaServer.

• For a list of known bugs and their workarounds, see Known Bugs. Please look at these before you report a bug.

• For answers to commonly asked questions about the JavaServer, see Frequently Asked Questions.

Top