> 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.
Yes, I agree with that. I've just added the call to your URL decoding method in the processor. No char decoding there (too many things are called the same; it's confusing). > > > > <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. Ok, I'll look at the code, try to use commons-logging, and see if the get/setLogger is really needed. Remy -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
