Mircea LUTIC wrote:
Hello Chris,
I will save Chris one answer :
1. If the filter does not influence the decoding of the GET parameters why is it called on GET requests?
Because the filter may want to, for example, modify or add request
headers to the request (or response headers). Or it may want to change..
the parameters, or rather the request's "query string" as a whole (the
part of the URL after the "?").
I think what Chris meant, is that the filter does not influence the way
in which a call like getParameters() works. The standard
getParameters() method takes the request URI (as it sees it by the time
it runs) and parses its query_string part into a table of parameter
names and values, according to fixed rules which you cannot change.
What your filter /could/ do, is to create a "request wrapper object"
containing the original request. This request wrapper would for example
pass an already-modifed request URI to the getParameters() method.
Or it could re-define the getParmeters() method, to return modified
parameter values.
When an application then runs and calls getParameters(), it will get the
result of the getParameters() of your wrapper object, instead of the
getParameters() of the original object.
For example, the result would be already-"translated" parameter
names/values.
(You have to do it this way, because the original HttpServletRequest
object is immutable, it cannot be modified directly.)
2. How about http : PUT, HEAD, etc?
Same thing.
And same thing for the request body, if any.
There are some additional nuances and details to what I wrote above, but
I hope that this already helps somewhat.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
