-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Konstantin,
On 12/23/11 3:41 AM, Konstantin Kolinko wrote: > 2011/12/23 Christopher Schultz <ch...@christopherschultz.net>: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> All, >> >> At the ApacheCon NA Tomcat meetup back in November, there was >> general interest in seeing some example servlet Filters in the >> Tomcat examples directory. I said I'd write some. It's time to >> put my money where my mouth was. >> >> I have the following filters already in my current project would >> could be edited a bit and put into Tomcat's examples. Is there >> any interest in the following: > > Only examples, or add them to catalina.filters ? The discussion at ApacheCon was mostly about example filters that people could use as a template for building other filters. I figure that "useful" filters could be used as both templates *and* directly-useful filters. So, my list was intended to include both types -- basically whatever I had laying around. >> 1. BrokenLocaleFilter -- fixes Opera 9's non-spec-compliant >> Accept-Language locale formatting (O9 uses en_US instead of >> en-us) > > Fixed in Opera 9.01 [1], and latest version is 11.60. Is it still > relevant? Anyway a broken browser will fail on a number of web > sites. > > If I treat it as a an example of implementing a filter, I do not > expect it to be of great demonstrative value. Fair enough: it's a fairly simple valve and actually sets the Locale in the HttpSession for use with Struts 1, so it's not terribly widely useful. It might have been better to wrap the request and "fix" the header as it was being read by the webapp. But we didn't do that :) >> 2. EncodingFilter -- sets request's character encoding when the >> client does not specify one. I think this is already in Tomcat -- >> I'll check > > SetCharacterEncodingFilter. > > I yesterday proposed its backport to 6.0 and 5.5 - one may vote. I should do that. It's a very useful filter and should definitely be in catalina.filters and not just in the examples. >> 3. CredentialFilter -- looks for a Printipal in the request and >> a missing User object in the HttpSession, and loads a User from >> (wherever) and puts it into the session. Essentially, this >> allows a webapp to do a "real" "login" after contained-manager >> authentication has done its job. > > I would say that that "whatever" part will be very specific to > your requirements. Definitely. This could be an abstract filter that has a method like this: protected abstract Object getUserObject(HttpServletRequest request); ...or something like that, intended to be overridden. We get questions enough on the list about how to get Tomcat to do a "login" and not just authentication that I figured it would be worth proposing. >> 4. HttpResponseSplittingPreventionFilter -- prevents HTTP >> response headers from containing CR or LF characters (features >> response wrapping) >> >> I also have this one sitting around. I think I wrote it on a dare >> for the tomcat-user list: > > Maybe use a different name and provide stronger validation of > headers and it might go into catalina.filters. Okay. I know you had some complaints about its simplicity at the time. I'd be glad to hear your thoughts on its implementation. I'll file a BZ enhancement and attach the source for discussion. >> 5. HttpConversationRecorderFilter -- this captures an entire >> HTTP request and response and dumps them to (somewhere -- >> currently stdout) after the request completes. Features wrapping >> the request and response objects. Features massive buffering (!) > > It might be interesting for debugging. It might be interesting as > an example of wrapping. Is that buffering something special? I do > not understand "massive" adjective here. It's only massive because it holds everything in a big buffer. It's not appropriate at all for production use unless you're experiencing a problem so bad that buffering (actually, copying and storing in memory) both request and response is tolerable in your environment. If this were intended to be very robust, it would do something like, after some size limit, use an on-disk buffer (or just truncate the request/response data or something). >> I'd also be happy to try my hand at other filters the community >> thinks would be generally useful as well as educational. > > As a start I'd suggest to file them as separate issues in Bugzilla. > I think we can go on from there. I'm certainly open to suggestions. I'm just not very creative, which is why I posted the list of Filters I have been forced to build over the years :) Thanks, - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk70lsgACgkQ9CaO5/Lv0PB7GQCgtQESz65Q3SSRYAx+aHt8/Bln TeQAnRv1D0vzLAC9KS5y/ZmPFtvbGwMb =M3xG -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
