tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: reading html-form parameters within servlet filter on tomcat 4.0.3
Date Wed, 03 Apr 2002 18:00:16 GMT

On Wed, 3 Apr 2002, Alexander Thomas wrote:

> Date: Wed, 03 Apr 2002 00:17:55 +0200
> From: Alexander Thomas <>
> Reply-To: Tomcat Users List <>
> To: Tomcat Users List <>
> Subject: Re: reading html-form parameters within servlet filter on tomcat
>     4.0.3
> Dear Craig,
> thanks for your swift reply! As you suggested I tried to foist the
> servlet a new instatnce of the BufferedReader class.
> The codesection in the doFilter method of my filter class looks like this:
> HttpServletRequestWrapper httpServletRequestWrapper = new
> HttpServletRequestWrapper() {
>         public BufferedReader getReader() {
>                 return new BufferedReader(new
> StringReader("testparameter=testvalue"));
>         }
> }
> chain.doFilter(httpServletRequestWrapper, response)
> However, this approach does not have an impact on the parameters present
> in the servlet!!

If you want to change the parameters that the servlet sees, just override
the getParameter(), getParameterNames() (and so on) methods in your
wrapper also.  You can "fake" pretty much anything.

> I am not very familiar with the debug option in catalina. Nevertheless,
> I used it and came to the conclusion that the servlet actually does not
> use the HttpServletRequest object while evaluating the getParameter method.

That's not really true, because your servlet really calls the
getParameter() method on the request object passed to doGet() or doPost().
But, I believe, your real question is how does the parameter lookup
*really* happen?

> Can you confir that?

In the absence of any application-provided wrappers or request dispatcher
calls, the request object that is passed to a servlet's doGet() or
doPost() method is:
- An instance of org.apache.catalina.connector.HttpRequestFacade,
  which has a reference to ...
- An instance of org.apache.catalina.connector.http.HttpRequestImpl
  (assuming the standard HTTP connector in 4.0), which subclasses ...
- The org.apache.catalina.connector.HttpRequestBase class, which
  in turn subclasses ...
- The org.apache.catalina.connector.RequestBase base class that
  is the lowest-level piece of Catalina directly related to the
  incoming request.

Generally, calls like getParameter() simply get delegated down the chain
until someone actually implements them.  In this particular case, the
standard implementation of getParameter() is in HttpRequestBase, where the
incoming parameters are parsed into a Map (if this hasn't been done yet)
and then used to retrieve the requested value.

Things change when you do things like a RequestDispatcher.include() call.
In that scenario, Catalina creates what amounts to a request wrapper in
order to implement the extra request attributes that an included servlet
sees (without modifying the underlying request at all).  When the include
returns, the wrapper is simply removed, thus restoring the previous

The same sort of thing happens when you write your own request and
response wrappers.  By default, all of the methods are simply delegated to
the actual request (or response) you are wrapping.  But, you can override
the getParameter() method yourself if you need to -- and the servlet that
is actually called will never know the difference.  In this way, a filter
can (for example) make some actual parameters disappear, or add some new
ones -- simply by customizing what really happens when getParameter() is
called.  But what actually happens is totally up to you as the author of
the wrapper class.

> Regards,
> Alexander Thomas


To unsubscribe:   <>
For additional commands: <>
Troubles with the list: <>

View raw message