tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Remy Maucherat" <r...@apache.org>
Subject Re: [PROPOSAL] Proposed integration of Coyote in 4.0-HEAD
Date Wed, 13 Mar 2002 07:35:16 GMT
> > 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:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message