struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jing Zhou" <>
Subject Re: Servlet Path & Path Info on Weblogic 8.1 vs. Struts
Date Wed, 24 Sep 2003 04:18:25 GMT

----- Original Message ----- 
From: "Craig R. McClanahan" <>
To: "Struts Users Mailing List" <>
Sent: Tuesday, September 23, 2003 6:44 PM
Subject: Re: Servlet Path & Path Info on Weblogic 8.1 vs. Struts
> >* On WebLogic 8.1 and OC4J 9.0.3, the filter is invoked when *.do
> >   action is received. When Struts forwards to (or includes) a target JSP
> >   page, the filter is invoked again (with wrapped http request and
> >   response in our case).
> >
> >
> Sigh ... there's actually two different issues here.
> * They should not be invoking the filters again (see above)
> * They should not be wrapping the request/response (most likely being
> done by their
>   implementations of RequestDispatcher)  See the last paragraph of
> Section 6.2.2
>   in the Servlet 2.3 spec.

My message was not clear. Only OC4J inserts a *filter* before it is invoking
my filter again (possibly in its RD implementation) in which my wrappers are
wrapped again. The OC4J wrapper class was mentioned below.

> >* In particular, OC4J wraps our http request and response wrappers
> >   using its own class
> >   when it is invoking the filter on the target JSP pages.
> >
> >
> It's possible you might be able to work around the wrapping bug by
> casting to HttpServletRequestWrapper and then walking up the wrapper
> chain by calling getRequest on it, then repeating until you get back to
> your own request wrapper class.

Yes. That's the way I found it by keeping unwrapping the wrappers.

> >I could not judge whose behavior is right or wrong. They are even
> >(2 to 2 here).
> >
> That makes not the slightest bit of difference if the behavior in
> question is actually defined in the spec.
> > From what I read in the Java Servlet Specification,
> >I couldn't find, for example, the servlet containers should invoke
> >the filter or not when using the request dispatcher to include and/or
> >forward to a target servlet. Is this an ambiguity here? or both ways
> >of implementation are allowed?
> >
> >
> For filters, see (for example) Section 6.2.1, where it says (** is
> around my emphasis added):
>     When the container *receives an incoming request*
>     it takes the first filter instance in the list and calls
>     its doFilter method ...
> where one infers that "incoming request" means an incoming HTTP request,
> not a RequestDispatcher call.  This was made clearer in 2.4.

I am in favor of Tomcat/Resin's behaviors, or the default behaviors
in Servlet 2.4 for the following reasons:

- If a filter protects mapped resources from being directly accessed,
   Tomcat/Resin allows web applications to forward or include the
   mapped resources. This is consistent when applications forward to or
   include resources under the /WEB-INF directory.

- The above assumption is broken if the filter is invoked again. Many
   developers write their security filters without such knowledge. Their
   applications could break because their forwards will be denied
   in WebLogic and OC4J. Even they know, they have to find a way
   to skip the security checking. A double checking is not necessary.

- If the mapped resources need some transformation filters in place
   (The only reason I could see they need to invoke the filter again),
   one way applications could do is to use redirect/rewrite techniques
   to invoke the transformation filters (because of incoming http requests).

>From Servlet 2.3, there is another thing not clear to me:
Could a servlet container execute the filters in a chain in different
for one incoming http request? I do not believe it should go this way,
but it looks to me this is possible and further complicates the filter
(The RD clearly requires the same thread to invoke target resources.)

> Craig

Netspread Carrier

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message