There are many ways to take advantage of Coyote in Tomcat 4, but I'd like to start with some limited changes at first. Most of these proposed changes are Coyote-related (hence the subject of the message), and all involve some refactoring / API additions.
A) URI decoding refactoring. To avoid doing some URI decoding in many places in the pipeline, a decodedURI field (with associated getter/setter) should be added in the HttpRequest interface, and used in the Catalina pipeline. This also has the advantage to guarantee that no double URI decoding occurs (which can lead to URI-based security attacks). <ballot> [ ] +1 [ ] +0 [ ] -1: </ballot> B) Use Coyote as the default HTTP connector in 4.0-HEAD, replacing the old connector, which has many shortcoming (slow performance on output, HTTP handling limitations and extreme complexity). Initial tests results and benchmarks with Coyote are extremely positive so far. <ballot> [ ] +1 [ ] +0 [ ] -1: </ballot> C) Add better lifecycle handling in the resources. A start method is needed (which could be called 'allocate' to mirror the 'release' method), because it is currently not possible to restart a stopped context. In the 4.0 branch, the patch introducing the 'release' method must either be reverted, or these proposed changes must also be ported to 4.0. Thanks to Jean-Francois Clere for the report and debugging of this problem. <ballot> [ ] +1 [ ] +0 [ ] -1: </ballot> D) Deprecate the o.a.catalina.connector package. This package *SHOULD NOT* be used for any new connector development. To make this more obvious, I'd like to deprecate all classes in this package and subpackages. The binaries will also be packaged in a separate JAR file (tentatively named catalina-legacy.jar). This package will continue to be maintained on a case by case basis. The facades will not be deprecated, and two new helper objects will be introduced to handle the need for "fake" req/resp when requesting a JSP precompilation with a load-on-startup (see bug 4518 for more details). <ballot> [ ] +1 [ ] +0 [ ] -1: </ballot> E) Use commons-logging in Coyote, by adding a get/setLogger on the Processor interface. Otherwise, the processor has no way to cleanly handle logging. commons-logging is already used by other j-t-c components. At the moment, the HTTP/1.1 processor "logs" problems as stack traces on the stderr; this needs to be improved. When I originally designed most of the base interfaces, commons-logging didn't exist yet, and I didn't feel like adding yet another logging interface. <ballot> [ ] +1 [ ] +0 [ ] -1: </ballot> +1 for everything. Thanks for voting / commenting :) Remy -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
