tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Cruikshank <>
Subject Problem losing post data during and after jsp:include
Date Fri, 10 Dec 1999 04:10:11 GMT
It seems that the RequestDispatcher is clobbering the post data in the 
Request object while processing a jsp:include.   I don't think this is 
expected behavior.  The code in RequestDispatcher.include() method:

Request realRequest = reqFacade.getRealRequest();
Response realResponse = resFacade.getRealResponse();
String originalQueryString = realRequest.getQueryString();
// join the query strings of the destination request
// with the originaing request in that order.
String aggregatedQueryString = this.queryString;

if (realRequest.getQueryString() != null &&
    realRequest.getQueryString().trim().length() > 0) {
    if (aggregatedQueryString == null) {
        aggregatedQueryString = realRequest.getQueryString();
    } else {
        aggregatedQueryString += "&" + realRequest.getQueryString();

if (aggregatedQueryString != null) {

// inline the aggregated query string for the scope
// of the include

// revert the query string to its original value

Only sets the GET parameters (the query string) in the request for the 
included file.  The Request.setQueryString() replaces ALL of the request's 
parameters with the parameters from the new query string (clobbering the 
post parameters).  When setQueryString() is called with the old query 
string, it replaces the old GET parameters, but not the old POST 
parameters, so the POST data is lost.

If I were to fix the problem, I would add a getParametersClone() method to 
Request that gets a clone of its parameters Hashtable and an 
addQueryString() method that would merge the new query string into the 
existing parameters.  RequestDispatcher could save the parameters clone 
instead of the old query string, and then replace it after the clone using 
the setParameters() method that is already in request.

Also, has anyone looked at the problems with the JspReader that I brought 
up last week?

Alex Cruikshank
Software Engineer

View raw message