> > 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 > > [X] +0 Already in the 3.3 code (and currently ignored in the 3.3 Adapter). > > [ ] -1:
Good, then you'll be able to use that field in TC 3 (the HTTP/1.1 should now populate it, and it uses the same decoder TC 3 uses; no surprise here). Also, I'm about to add in the TC 4 adapter the code used in TC 4 to prevent some URL based attacks (with a flag allowing to disable the checks, though, as this may be useless in the HEAD branch after the proposed refactoring). However, I know that TC 3.3 has that kind of nomalization code also, so maybe you should check to be sure you don't need it (maybe in 3.3 it's not part of the connector; I don't remember). > > 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> > > [X] +1 I couldn't ever find the "fake" req/resp for 4518 (ok, in 3.3 > land, any class that ends in "Base" is an abstract class. ;-) > > [ ] +0 > > [ ] -1: > > > > </ballot> Here, I got lucky and was able to just use HttpRequestBase/HttpResponseBase, just populate a few fields and have it work. Obviously, it is a complete hack, so I plan to add some dummy request/response objects which could be used for this instead. > > 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> > > [X] +1 I'm guessing that Costin & Larry will have fits with this (TC 3.3 > currently has no dependencies on outside packages). However, my support is > only if it gets into o.a.c.Processor. It shouldn't be a http11 only issue. > > [ ] +0 > > [ ] -1: > > > > </ballot> Yes, that's a good point. JK 2 is using commons-logging already, so I think the dependency on that component is inevitable no matter what. I'd rather live without it, but I'm very unhappy at the moment of having no logging at all inside the processor. Yes, the get/setLogger will go in the Processor interface. Remy -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
