On Tue, 12 Mar 2002, Remy Maucherat wrote: > 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).
No, the charset decoding is in DecodingInterceptor and is independent of connector. The connectors only deals with receiving/sending bytes, they have no idea about encodings or chars. The encoding may well be stored in the servlet session ( this is the only reliable way to deal with current browsers ), and in 2.3 it may be specified by the user. Having a 'decoded' field in the Request is very usefull, but computing it in the connector would be a mistake IMHO, as it'll potentially require access to higher layers. BTW, there is some decoding that may be required ( when Strings are still used ), but the real decoder will set the right charset and may reconvert. URL decoding is also included in the main decoder, but can be done in the connector. > > > <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. Jk2 is using commons logging interfaces. Note that the model is based on pull, not push - so get/setLogger are not needed. The main benefits over current 3.3 logging - it allows much finer granularity for logging/info and already supports log4j/jdk1.4. My plan is to do a small performance test on QLog vs. log4j/1.4, and if the results are positive ( QLog has few features, but is quite 'tuned' ) make QLogger implement commons logging. 3.3 has no dependencies external to apache - jaxp is required ( but easy to replace the impl with a smaller one ), and each module may have its own dependencies (jk2->logging). I do plan to add a dependency jk2->openjmx, at the moment it seems the best way to provide runtime manageability of the connector and the recent changes in the C side are in this direction ( i.e. jk2 will have a proxy/remote mbean that will manage mod_jk ) The commons-logging 'core' is comparable in size and power with tomcat.util.log, so I see no problem moving to a common log. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
