Geoff Soutter wrote:
>
> "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.
Boy, I'm sure not -- especially in the use case I described above. I'm
not at all liking the thought that all that content I thought was
protected is open to the world, simply because I mis-typed a database
password in the configuration parameters.
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.
Yes, you're right ... it doesn't know the UnavailableException came from
a Filter, so it marks the servlet unavailable instead. I changed the
second option description a couple of times before sending that
response, and forgot to correct the description of what Tomcat 4.0
actually does right now.
>
> > > 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.
>
It's going to be -- that has already been discussed in the expert
group. Filter chains (and security constraints) apply only on the
initial request, not on RequestDispatcher invocations.
> 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?
The rationale that makes sense to me (in addition to the simplicity
argument) is that the original filter chain filters a *servlet*. What
that servlet does inside it's service() method to produce the response
is a "black box" operation that is totally up to that servlet, which can
perform its own filter-like activities if it needs to.
>
> Cheers
>
> Geoff
Craig
