Erm. ok. Where does the redirectURL variable come from? Unless it has
parameters encoded into it that will be your problem.
Also, be a bit wary in using the RequestDumperValve with non-ascii
charset data as it can corrupt some parameters:
http://marc.theaimsgroup.com/?l=tomcat-user&m=112530311007782&w=2
The above (and other similar threads on this list) is why I tend to use
the browser plug-ins first.
Jon
rache wrote:
This is how the code redirects:
if (redirectURL.toUpperCase().startsWith("/SERVLET"))
{
// routing to another request to the servlet...
response.sendRedirect(request.getContextPath() +
redirectURL);
}
else if (redirectURL.toUpperCase().startsWith("HTTP"))
{
// routing to another request to the servlet...
response.sendRedirect(redirectURL);
}
else
{
// routing to a JSP...
getRequestDispatcher(redirectURL).forward(request,
response);
}
-Jon, we have enabled the RequestDumperValve in the tomcat server.xml to
enable request logging. That way, we are able to monitor the requests coming
in. The logs helped us to see that no parameters where set in the request.
This application is connected to IIS thru the AJP connectors. Aside from the
parameter-setting code which I need to check, could this connection also
cause request parameters to be dropped? I have quite a bit of a problem
checking the urls with parameters set since this happens in production and
happens on and off. I can't even see the page source to check on the url set
since the pages aren't cached. Any tips on these?
I'm really grateful for all your inputs!
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
