(Thanks to Geoff for prodding me to respond to this :-)
Danny Coward (specification lead for Servlet 2.3) is going to comment separately
on the spec related aspects of the questions below. I'll stick mostly with the
Tomcat 4.0 implementation stuff, and express a few options -- but they aren't
authoritative (Danny's are :-).
Geoff Soutter wrote:
> Hi there,
>
> I've got some questions about Servlet API 2.3 Filters and the Tomcat 4.0 m4
> implementation of them.
>
> I've been thinking about implementing one of those new-fangled Filter
> things. I've been reading the spec, and I've found a few things which are
> unclear. I've also read the source for Tomcat 4.0 m4 where appropriate to
> try and figure out what is currently implemented, and I'd like to know how
> the implementation relates to the unclear areas that I've found in the spec.
>
> The areas I'm confused about follow:
>
> 1) Filters and UnavailableException
>
> Filters can throw UnavailableException, but the 2.3 PFD doesn't seem to
> specify what to do with them if it does. It looks like Tomcat 4.0 m4
> disables the Servlet that the request referenced. This doesn't seem like a
> very good idea to me, primarily because there is not necessarily a 1:1
> mapping between a Filter and the Servlet it is filtering.
>
> For example, imagine if you had an authentication filter which was
> protecting a few static files in a subdir of your context. If the filter
> died and thew UnavailableException, that would mean that the DefaultServlet
> which is serving all the static content for your webapp would be disabled.
>
The choices seem to be:
* Start skipping this filter when building the chains.
* Block all requests that would normally invoke this filter.
I'm inclined to be worried by the first alternative -- especially if we started
skipping an authentication filter simply because it couldn't open its user
database. My personal preference would be for the second interpretation.
NOTE: Tomcat 4 currently does the second one, but it also marks the servlet
itself as unavailable, which is clearly not correct.
>
> Perhaps in this case the Filter itself ought to be disabled? It would be
> more work, but it would seem more consistent.
>
> 2) Filters and RequestDispatcher
>
> Filters are apparently allowed to call the include() and forward() methods
> of RequestDispatcher. However, the 2.3 PFD doesn't seem to mention if those
> calls should invoke the filter chain again or if they are supposed to
> reference the target servlet directly. It looks like Tomcat 4.0 m4
> references them directly. I'm not sure which is the best way, but I can see
> some potential problems with the way Tomcat is doing it.
>
My understanding is that the filter chain is constructed only on the original
request -- not on RequestDispatcher invocations. Same thing, by the way, for
security constraints. They get enforced only on the initial request URI.
>
> For example, imagine if you had a nice site you'd written in XML and which
> used an XSLT filter transform the content into HTML. Then, you wrote an
> authentication filter which is inserted in the filter chain before the XSLT
> filter. It forward()s to "login-error.xml" when the user enters the wrong
> password. What happens? the login-error.xml is sent to the client directly,
> without the XSLT transformation. Not nice.
>
This one sounds like an application issue to me. The fact that you might be
using a request dispatcher or not isn't really relevant -- the issue is an order
dependency in the filters. Isn't it enough just to say "you must put the XSLT
filter first" in the deployment descriptor, so that the transformation always
happens last?
>
> Would anyone care to comment on what they think is the right behaviour in
> these cases, or to clarify my confusion?
>
> Cheers
>
> Geoff
Craig
