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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>