[PATCH] bug 14436 - "RequestDispatcher Drops Query String"

[John Downing <JD...@buildonline.com>]

This is regarding (alleged) bug 14436 - "RequestDispatcher Drops Query
String"

Noticed 14436 in the Bug Database. We had two situations that were almost
identical. One where the resource path to dispatch to (a servlet) had its
own query string .. the JSP page that the servlet then forwarded to was
unable to see the query string from the original, dispatching request. 

And one where a dynamically included JSP page was not able to see request
parameters from the page it was included in (unless they were explicitly
passed in using jsp:param).

The following patch fixed both situations, so am including it in case it's
useful for anyone else. 

Whether or not it fixes 14436, or is the behavior required by the spec, is
something I haven't had time to look into. As is how far this works with
nested dispatches .. the existing code stores separate references to
appRequest, outerRequest etc .. not sure if  a proper fix will need to store
appQueryString, outerQueryString, etc, rather than just concatenating them
together ?

Anyway, hope it helps :)

Cheers,
John

PS - this is the first time I've sent in a patch (or indeed contributed to
the list) so if I'm doing anything wrong please let me know. I gotta learn
(!)


Index: ApplicationDispatcher.java
===================================================================
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/co
re/ApplicationDispatcher.java,v
retrieving revision 1.30
diff -u -r1.30 ApplicationDispatcher.java
--- ApplicationDispatcher.java	9 Jun 2002 05:45:04 -0000	1.30
+++ ApplicationDispatcher.java	19 Jan 2003 12:16:53 -0000
@@ -811,7 +811,23 @@
         this.outerResponse = response;
         this.including = including;
 
+        // Workaround for (alleged) bug 14436 - the resource we're
dispatching to doesn't
+        // otherwise see the query string of the request we're dispatching
from ..
+        if (request instanceof HttpServletRequest) {
+            String requestQueryString =
((HttpServletRequest)request).getQueryString();
+            
+            if (requestQueryString != null) {
+                if (this.queryString == null || this.queryString.length()
== 0) {
+                    this.queryString = requestQueryString;
+                }
+                else {
+                    this.queryString += "&" + requestQueryString;
+                }
+            }
+        }
     }
+
 
 
     /**

>Hello,
>
>I'm using TC 4.1.12 on Win 2k. I'm using the TC Coyote Connector.
>
>I've checked the Servlet v2.3 spec and the behavior I'm seeing in TC seems
to 
>go against the spec. In general, the problem is that the original query
string 
>is not properly aggregated when a servlet is invoked using a
RequestDispatcher 
>where and the target servlet has its own query string. Here's an example:
>
>I have a servlet called "servletA". Let's say "servletA" is invoked from a 
>browser with this URL:
>
><http://localhost/tst/ServletA?x=1>
>
>Within "servletA" we create a RequestDispatcher for "servletB" and then
forward 
>to "servletB" like this:
>
>RequestDispatcher rd = request.getRequestDispatcher("servletB");
>rd.forward(request, response);
>
>In "servletB", a call to "request.getQueryString()" returns the string
"x=1". 
>In other words, "servletB" is able to "see" the query string used to 
>invoke "servletA". Okay, so far, so good.
>
>Now, here's the problem: If "servletA" appends a query string to "servletB"

>when creating the RequestDispatcher like this:
>
>RequestDispatcher rd = request.getRequestDispatcher("servletB?z=1");
>
>"servletB" will only see the query string, "z=1", it will *no longer* see 
>the "x=1" query string.
>
>What I *expect* to see in "servletB" is a query string "x=1&z=1" -- i.e., 
>*both* query strings.
>
>Let me quote from SRV.8.1.1 (Servlet 2.3): "Parameters specified in the
query 
>string used to create the RequestDispatcher take precedence over other 
>parameters of the same name passed to the included servlet."
>
>In my example, the parameter names are *not* the same ("x" and "z") so the
"z" 
>parameter should not take precedence over "x". Also, the quote above refers
to 
>the "included servlet". I believe this generically refers to forwarded
servlets 
>as well. The example in the spec just happens to be using include() rather
than 
>forward().
>
>Finally, I would like to mention what happens if you use the 
>RequestDispatcher.include() method rather than forward(). Using my example 
>above, if you change forward() to include(), "servletB" will only see the
"x=1" 
>query string. It will *never* see the "z=1".
>
>One last quote from the servlet spec (SRV.8.4.1): "The request dispatching 
>mechanism is responsible for aggregating query string parameters when 
>forwarding or including responses."
>
>So, can you confirm that this is a bug?
>
>Thanks very much...






--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>