JavaServer

Contents / New Features / Administrator Docs / Developer Docs / Index

Java Web Server Release Notes

This document contains:

Java Web Server 1.1.1

This section of the document contains JWS 1.1.1 updates to the following sections:

Supported Environments

The Web Server is officially supported only under the SolarisTM SPARCTM and Windows NT environments. Windows 95 is supported for development but is not recommended for deployment because Microsoft does not consider it a server platform.

The Java Web Server runs on any platform that supports the Java Development Kit 1.1 or above.

Prerequisites

UNIX Platforms - Hardware and Operating System Prerequisites

Windows Platforms - Hardware and Operating System Prerequisites

Code Changes in Java Web Server 1.1.1

Session Tracking

Session Tracking is now handled on a server basis, rather than by service. To reflect this:

Presentation Templates

The template servlet has been split into two parts. One part, still called the TemplateServlet is the traditional servlet that is named "template" in the system. The new part is the TemplateFilter and is named "templatefilter". If you need to filter content from JHTML or SSI into the Presentation Template engine, use the templatefilter. This fixes a bug present in the TemplateServlet that shipped with 1.1.

Documentation Changes since Java Web Server 1.1

Adding users to the UNIX realm in Java Web Server

The documentation regarding adding users to the UNIX realm (information available through "Help" button on the Users screen of the Administration Tool or directly at /system/doc/administration/user.html) erroneously states the following:
NOTE: On the UNIX realm, it is not possible to add a user through the Java Web Server. The UNIX realm is controlled through the DNS database and users must be added through that mechanism.
Of course, the reference to DNS (Domain Name Service) is incorrect, it should have said NIS (Network Information Service).

Reading Passphrases from a File

It is possible to configure the Java Web Server to use a stored passphrase at startup rather than prompting the user to provide it. When the httpd process is invoked with the passfile option (httpd -passfile), it expects to find the passphrase in the keys.passphrase file of the server root directory. The keys.passphrase file stores the password as plain ASCII text. Storing the passphrase in such a fashion is a potential security risk.

To create a keys.passphrase file:

  1. Run the authstore utility.
    The authstore executable is in the bin subdirectory of the Java Web Server root.
  2. Create a plain text file, using your favourite editor, whose only content is the password.
  3. Save the file as keys.passphrase to the Java Web Server root directory.

To use the stored password when manually starting the Java Web Server on either Solaris or Windows platforms:

  1. Change to the bin directory of the server root:
    % httpd -passfile
  2. Invoke the startup script
    % httpd -passfile

To use the stored password when you are set up for automatic server start-up on the Windows NT platform:

  1. Open the control panel for start up parameters
    Start -> Settings -> Control Panel -> Services -> Startup Parameters
  2. Complete the text window with the parameter -passfile.

You will need to use the passphrase file if all 3 of the following conditions are true:

If this is the case, when the Java Web Server boots and it goes to bring up the Secure Web Service, it needs a password. However, an NT service has no way to communicate with the desktop so it isn't able to tell the desktop to put up a dialogue box asking for the passphrase.

That's why, in the above case, you would have to have a passfile in the proper place (as described above) with the passphrase in it. The Java Web Server will automatically look for the file and use it if it is there.

Page Compile and Security

The Java Web Server gives you a simple, yet powerful way to create dynamic web pages -- embedding Java code in an HTML file. When the hybrid HTML/Java page (identified by its .jhtml extension) is requested, the underlying Java Web Server mechanism compiles the page into a servlet and runs it. This feature is called Page Compilation.

The security mechanism for page-compile servlets is simple:

Note: This reflects a change in the security model of page-compile servlets between the Beta and final (FCS) versions of Java Web Server 1.1.

Bug Fixes in Java Web Server 1.1.1

This section contains a listing of the more important bugs fixed in the Java Web Server 1.1.1 release. Entries in parentheses indicate the same entry appears earlier in the list.

Bug Id Description
Servlets 
4117402 CGI-programs invoked by CgiServlet cannot work with TCP/IP
4102382 Directory listings created by FileServlet are invalid HTML
4103370 Servlets are being init()'d more than once
4109986 PageCompileServlet handles <FORM> tag incorrectly
  
CGI 
(4117402 CGI-programs invoked by CgiServlet cannot work with TCP/IP)
4098278 Changes to the cgi script directory are not dynamic
4098182 win32: Server needs to be restarted for cgi to work
  
Startup/Shutdown 
4107883-Dsystem_property=value argument not working in jserv script
4106944win32: Double quotes inside the PATH environment variable does not allow httpd start
4099422win32: Can't start httpd or authstore if installing on directory with spaces
4107869 Can't shut down the server when session tracking is turned off.
  
Session Tracking 
(4107869 Can't shut down the server when session tracking is turned off.)
4109927 Sessions aren't shared across services in same server
  
Security 
4109874 ErrorServlet generates <base href> tag, causing failure of secure sessions.
4100694 HEAD /protected.html returns a 401 Unauthorized even if you send authorization code
  
DO, PUT, GET, DELETE 
4093380 win32: Does not use the archive directory when HTTP PUT overwrites file.
4097982 DELETE/PUT are allowed when Security Check is disabled on admintool.
4098129 win32: PUT does not flush last few files that are PUT
  
Page Compilation 
4109986 PageCompileServlet handles <FORM> tag incorrectly
4087488 HEAD returns content length of 0 for shtml and jhtml files
  
Miscellaneous 
(4087488 HEAD returns content length of 0 for shtml and jhtml files)
4102375 Spaces of a File Name in Directory Listing are Not Escaped
4098844 addservice utility throws NullPointerException when server has keys file
4102524 MIME type for *.Z doesn't work
4114495 Bogus errors appearing in errorlog - IllegalAccessException
4103115 Servlet chaining doesn't pass headers.
4116549 Java Web Server 1.1 does not log NullPointerExceptions to error_log

More Tips, Tricks, and Troubleshooting

Troubleshooting Servlets

The sendRedirect and sendError methods of HttpServletResponse are convenience methods. Each is intended to be the only method called in response to a request.

sendRedirect and sendError each create a complete response object by performing the following calls: setStatus, setHeader (in the case of sendRedirect), setContentLength, and then a series of println's. For this reason, neither sendRedirect nor sendError should be used where you are need to manage a part of the response explicitly. (For instance, you would not call either of these methods just after you set the status or just before you print to the output stream.)

If you use the sendRedirect or sendError methods incorrectly (for instance, in conjunction with println),you will get a "write past end of stream" error message.

The CLASSPATH Environment Variable and the Java Web Server

People are sometimes confused about how the CLASSPATH variable is used with the Java Web Server. Here's a quick overview.

The Java Web Server ships with a Java Runtime Environment (JRE). By default, the Java Web Server uses this included JRE -- which means you don't have to be concerned about your CLASSPATH or JAVAHOME settings, their values are ignored unless you explicitly say otherwise when you start the server.

If you want the Java Web Server to find and access additional classes (for example, ones you've written), you can do this in any of the following ways:

In all of the above cases, <server_root> refers to the directory containing the installed Java Web Server product.


Java Web Server 1.1 Trial Version
Release Notes

Contents / New Features / Administrator Docs / Developer Docs / Index

This document has the following sections:

New Features of the Java Web Server

Page Compilation

Page compilation allows JavaTM and HTML to be integrated on the same page. The Java code controls the output on the page, because the page is compiled into a servlet before the output is sent to the client.

Session Tracking

Sessions give the stateless HTTP protocol the ability to maintain state between requests to the server. The state is maintained via server-side cookies and/or URL rewriting.

Templates

Templates allow the look and feel of a web site to be customized, without having to change every web page within that site. The template "wraps around" HTML documents to present a consistent user experience.

HTTP 1.1

JavaTM Web ServerTM 1.1 implements the HTTP 1.1 protocol. As such, the Java Web Server now supports content negotiation, chunked encoding, byte range operations, caching, and persistent connections. In addition, the methods PUT, DELETE, OPTIONS, and TRACE are also implemented. Note that PUT and DELETE are restricted to protected resources only.

File- and Gif-Upload Servlets

These basic upload servlets handle uploads as performed by NetscapeTM browsers versions 3 and 4.
Note: it is not an implementation of RFC 1867; it is merely a subset of it.

Enhanced Security Features

New security features include support for NT realms as well as support for more Certificate Authorities than the five precompiled ones in the 1.0 version of Java Web Server.

Servlet Beans

Now you can use servlets that are also beans. The servlet bean adheres to the JavaBeansTM design patterns, allowing you to get or set properties and to save state in serialized files.

Notes on the Trial Version

The Trial Version of the Java Webserver contains all the features of the full version of the API. However, the number of simultaneous connections allowed to it has been limited to 5. This means that if more than one browser at a time connects to it, the response will be either be extremly slow, or connections may be rejected. As a side effect of this limitation, you will not be able to adjust the maximum or minimum number of threads in the admin tool.

To obtain the full version of the JavaWebServer, please to go The Javasoft Web Site, and purchase a copy.

Changes to the Servlet API

The following are the latest additions to the Java Servlet API. These additions are upwardly compatible for servlet developers. They will, however, affect developers who write servers that load and use their own servlets, and developers who write servlet-embedding engines.


Supported Environments

The Web Server is officially supported only under the SolarisTM SPARCTM and Windows NT environments. Windows 95 is supported for development but is not recommended for deployment because Microsoft does not consider it a server platform.

The Java Web Server runs on any platform that supports the Java Development Kit 1.1 or above.

Prerequisites

UNIX Platforms - Hardware and Operating System Prerequisites

The compressed file is approximately 14 MB.
To install it, you require roughly 20 MB of hard drive space.

Windows Platforms - Hardware and Operating System Prerequisites

The compressed file is approximately 10 MB.
To install it, you require roughly 13 MB of hard drive space.

Additional Requirements

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

For the server environment, you need EITHER:

In addition, on Windows 95, you need:

For the the client environment, you need:

Known Bugs

This section contains workarounds for some of the bugs known at the time of the Java Web Server 1.1 release.

For the most up-to-date list of bugs and their workarounds, JavaSM Developer ConnectionSM members should see the Bug Parade page on the Java Developer Connection web site. Please look at these before you report a new bug.

Note: Java Developer Connection membership is free but does require registration for access. Details on how to become a Java Developer Connection member are provided on JavaSoft's For Developers web page.

Netscape Navigator Versions 4.02 and 4.03

On UNIX, the Administration Tool will not run on Netscape Navigator versions 4.02 or 4.03. Please use an earlier version of Netscape Navigator or use version 4.04 instead.

Removing Java Web Server on the Windows Platform

On Windows NT 4.0, if you installed the Java Web Server as an NT service, you must remove it in two stages:
  1. Issue a command to de-register the Java Web Server with the NT Service manager.
    1. C> cd server_root\bin
    2. C> jservsvc JavaWebServer remove
    3. where server_root is the name you chose for the directory into which you installed the product. By default, the install program names that directory JavaWebServer1.1

  2. Remove the Java Web Server itself, which you may do by automatic or manual means.

    To remove it automatically:

    1. Click on the Control Panel.
    2. Click on Add/Remove Programs.
    3. Highlight on the Java Web Server entry in the window and then click on Add/Remove.

    or, to remove it manually:

    1. C> cd server_root
    2. C> rm -r *

User Login Names with Spaces Not Allowed

User names that contain spaces are not allowed in the Java Web Server. If you try to log in to the Java Web Server Administration Tool with a user name that contains spaces, you will not be able to get in.

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.

Permissions on Logs

When first installed, no log directory is created. It is created by the server runtime the first time the server is started. Permissions on the logs are granted based on the user running the server at this initial time.

For example, if you run the server for the first time as a usernameA, the logs are owned by usernameA. Subsequent runs by any other user (including root) will result in a "failure to open logs" error due to permission problems.

To correct this problem, either run the server for the first time as "nobody" or reset the permissions on the logs.

Environment Variables with Quoted Strings Won't Work

Under Windows NT, environment variables set using quoted strings will cause the httpd program to exit without warning. For example, using the following setting will cause trouble for the startup scripts found in $SERVER_HOME/bin:
JAVA_HOME=C:"\PROGRAM FILES\JAVA"

The affected variables are PATH, JAVA_HOME, and CLASSPATH.

Microsoft Internet Explorer and HTTPS

Some versions of Microsoft Internet Explorer, including 3.0 and 3.01, have been observed to crash when using the Secure HTTP protocol (HTTPS) to talk to the Java Web Server. This is a bug which Microsoft appears to have fixed in more recent versions of Internet Explorer, such as IE4.0b1. If you have problems using HTTPS, either use another browser, such as Netscape Navigator 3.0 (or later), or get the bug-fixed version of Internet Explorer from Microsoft.

Tips, Tricks, and Troubleshooting

Extracting TAR archive on UNIX

If you extract the Java Web Server 1.1 release on UNIX, using some user account other than "root", you should be aware that the "TAR" command will use your UMASK when creating directories, and this can create security holes. The distribution has no need for any files which are writable by "group" or "world".

To work around this problem, either

OR

Changing Your Admin Password and Default Port

Once you have installed the Java Web Server on your system and logged in to the Administration Tool, it is recommended that you take the following two steps to provide additional security for your Java Web Server:

For details on doing how to perform these steps, see the Properties document.

If You Have Lost Your Password

If, by chance, you change your Administration password and then forget it and can no longer get access to the Java Web Server Administration Tool, you can recover by following these steps:
  1. Stop your Java Web Server.
  2. In your favorite text editor, open the file
    server_root/realms/data/adminRealm/keyfile
  3. Change the admin line there so that it reads:
    admin::YWRtaW4=
  4. Save the file.
  5. Restart your Java Web Server.

If you are Locked Out of the Java Web Server

Although it is recommended that you take every opportunity to protect your Java WebServer by using the security tools provided with the product, it is not recommended that you assign access controls to any of the core internal servlets. Assigning access controls to any of these servlets can prevent you from having normal access to your Java Web Server. These include the admin, error, file, invoker, linkcheck, loganalyzer, snoop, cgi, and ssinclude servlets.

If, by chance, you do find yourself locked out of the Java Web Server 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 assigned the access controls.

To edit the acl.properties file:

  1. Change to the directory
    server_root/properties/server/javawebserver/service_name
  2. Open the file acl.properties in your favorite text editor.
  3. Look for the line that contains the name of the servlet and its realm. Comment this out 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 Java Web Server processes.
  5. Close your browser then re-open it.
  6. Restart your Java Web Server.

You should now be able to log in normally to the Java Web Server.

Maintaining Security When Changing the Document Root

In some cases, changes made to the Java Web Server are not dynamic and do not take affect until the server is restarted. For example, if you have protected files in your document root directory and you create a new document root and move them there, you will lose authentication on them until you restart the server.

If you change your document root and move protected files to it, you must restart the server.

To restart the server:

  1. Open the Administration Tool.
  2. Select Web Service.
  3. Select Stop.
  4. Select Restart.

File Descriptors

Due to the streamlined single-process nature of the Java Web Server, a large number of file descriptors may be in use at any one time. On some systems under high load, the default number of file descriptors your system supplies may not be enough. If your system begins to run out of file descriptors, you may see failed class loads messages, refused sockets, and other errors related to not being able to open files. To find out how to increase the number available to your process, please consult the system management guide for your platform.

Customized Logging with Custom Classes

To log requests, you specify a value for the log.name.formatclass property in the systemdefaults.properties file. The name parameter represents the type of logging and can be either error, event, access, agent, or referer.

For example, events are logged through the Tracelog class by default. Thus the entry for logging events in the systemdefaults.properties file is:

log.event.formatclass=com.sun.server.log.Tracelog

If you customize your logging with custom classes, you need to change the value of log.name.formatclass to point to the name of the custom class that will handle the requests for the various types of logging. For example:

log.event.formatclass=com.sun.server.log.MyEventLogFormatter

You will also need to subclass the appropriate classes and override the appropriate methods.

In both cases, (extending tracelog and httplog) all writing to the system logs should be done with the print() methods of sun.server.log.Log. Also, access to the system logs output stream can be obtained by using the getOutputStream method of Log.

Java Web Server and The JDBC-ODBC Bridge

We recommend that people do not attempt to use the JDBC-ODBC bridge with the Java Web Server 1.1 product. We instead recommend that users use only Pure Java JDBC drivers. Drivers that use native code are subject to platform vagaries that can crash the Java Web Server entirely.

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

Changes Requiring Server Restart

If you find that changes you have made do not seem to be getting updated in the Web Server, try restarting it. Restarting the server should ensure the necessary update for tasks such as the following:

Not Recommended - Reading Passphrases from a File

While it is possible to configure the Java Web Server to use a stored passphrase at startup, rather than prompting the user to provide it, this is discouraged. When the httpd process is invoked with the passfile option (httpd -passfile), it expects to find the passphrase in the keys.passphrase file of the server root directory. The keys.passphrase file stores the password as plain ASCII text. Storing the passphrase in such a fashion is a potential security risk and therefore is not recommended.

To use the stored password when manually starting the Java Web Server on either Solaris or Windows platforms, type:

  1. Change to the bin directory of the server root:
    % httpd -passfile
  2. Invoke the startup script
    % httpd -passfile

To use the stored password when you are set up for automatic server start-up on the Windows NT platform:

  1. Open the control panel for start up parameters
    Start -> Settings -> Control Panel -> Services -> Startup Parameters
  2. Complete the text window with the parameter -passfile.


Top
java-server-feedback@java.sun.com
Copyright © 1997 Sun Microsystems, Inc.
All Rights Reserved.