"Craig R. McClanahan" <[EMAIL PROTECTED]> wrote:
> (Thanks to Geoff for prodding me to respond to this :-)
thanks to craig for responding :-)
> > 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.
I personally favour the second one. Are you sure TC it already does this?
>From my (very) quick reading of the code it appeared it only disabled the
underlying servlet, and left the filter in operation.
> > 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?
I guess it comes down to "what are the semantics of forward() wrt filter
invokation?". I assumed that a forward() to another page will ignore any
filtering applied to the original request, and thus for it to make sense it
would need to use another filter chain. Looks like you are thinking
forward() to another page will respect any filtering applied to the original
request, and thus does not need to use another filter chain. I guess this is
another issue that needs to be clarified in the spec.
Saying that I would have thought that it would be more useful and flexible
(and probably slower and more complex to implement) if each forward() call
had it's own filter chain. Or perhaps if you could configure the call to
work either way that may be best?
Cheers
Geoff
