tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Servlet Filter Examples
Date Fri, 23 Dec 2011 14:57:12 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Konstantin,

On 12/23/11 3:41 AM, Konstantin Kolinko wrote:
> 2011/12/23 Christopher Schultz <chris@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message