Tomcat User's Guide. This document is an introduction to the Tomcat 3.3 servlet container.
It should be enough for anyone to install, configure and deploy Tomcat 3.3, or it's maintenance releases. As well, it answers many questions common to new users. If you have any comments or suggestions about this document don't hesitate to send them to the Tomcat mailing lists. Since Tomcat 3.3 is a reference implementation of the Servlet 2.2 and JSP 1.1 specification, it would be very beneficial to become familiar with these documents, to better understand much of the behavior that Tomcat 3.3 implements.
The Servlet 2.2 specification may be obtained here and the JSP 1.1 specification obtained here One of the features of Tomcat 3.3 is its upgradability via add-on modules (though this feature is not yet well documented). Tomcat 3.3 can operate as a standalone web server. Other important documents: Table of Contents About Tomcat: Q&A See also the official Jakarta FAQ Page. What is Tomcat? Where can I download Tomcat? The Apache Tomcat Native - Documentation Index. Apache Tomcat - Apache Tomcat. FAQ. FAQ/Connectors. Preface Please see the Other Resources Link for other pages describing how they were able to link Tomcat with a connector.
With luck, someone documented their experience in an environment which is similar to yours. Here is a link to the JK Connectors. It contains more configuration and installation information. Please note, jk2 is no longer supported. Questions Answers What is JK (or AJP)? AJP is a wire protocol. Which connector: mod_jk or mod_proxy? Mod_jk is mature, stable and extremely flexible.
Here are some anecdotal comments from members of the Tomcat community: I have been using mod_jk for a very long time and I saw (at the time) only one reason to make the switch to mod_proxy_ajp: it is bundled with Apache and so you (likely) don't have to build the module yourself. That said, simple configurations are *way* more simple in mod_proxy_ajp than with mod_jk, although the (somewhat) recent addition of JkWorkerProperty and JkMount "extensions" do help quite a bit.
FAQ/CharacterEncoding. Questions Answers Why What is the default character encoding of the request or response body?
If a character encoding is not specified, the Servlet specification requires that an encoding of ISO-8859-1 is used. The character encoding for the body of an HTTP message (request or response) is specified in the Content-Type header field. References: HTTP 1.1 Specification, Section 3.7.1 The above general rules apply to Servlets. Why does everything have to be this way? Everything covered in this page comes down to practical interpretation of a number of specifications. Default encoding for request and response bodies See 'Default Encoding for POST' below.
Default encoding for GET The character set for HTTP query strings (that's the technical term for 'GET parameters') can be found in sections 2 and 2.1 the "URI Syntax" specification. Some notes about the character encoding of URIs: ISO-8859-1 and ASCII are compatible for character codes 0x20 to 0x7E, so they are often used interchangeably. How 5.x 6.x. FAQ/Performance and Monitoring.