Details
Description
When a forward is made using RequestDispatcher.forward(), Jetty merges parameters in existing request with parameters of forward (i.e. those that are specified in a query string of path used to obtain a RequestDispatcher).
If the same parameter is both in existing request and in forward path, both parameter instances remain in the query string after the forward.
I'm going to attach a test webapp. It has two servlets, one of them is SourceServlet, bound to /source context, another is TargetServlet, bound to /target context.
doGet() method of the TargetServlet is
protected void doGet(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException
So it just dumps the query string.
doGet() method of the SourceServlet is
protected void doGet(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException
It forwards to TargetServlet using a query string 'name=forwardValue'.
After deploying webapp with these two servlets to Jetty and going to the following path:
/source?name=initialValue
we see the following in the output:
name=forwardValue&name=initialValue
So, both values are in the resulting query string after the forward.
But the Servlet specification says:
"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."
(servlet-2_4-fr-spec.pdf, page 64, section 'SRV.8.1.1 Query Strings in Request Dispatcher Paths')
So it seems that when parameter with the same name is encountered in initial request and in forward path, the latter should take precedence and the former should be eliminated.
When repeating steps described here in Tomcat, I see the following output:
name=forwardValue
I.e. in Tomcat parameter from forward path takes precedence.
I recall there was a bug submitted to the sourceforge tracker, at that time Jetty was hosted there (it was near its 5.1.5 version). Seems that this bug is same as that one. As for that (old) bug, one of Jetty developers commented that this will be fixed and it seemed to be fixed, but now its here again.
The only thing from that sourceforge issue is link: https://sourceforge.net/tracker/?func=detail&atid=107322&aid=1262990&group_id=7322
It seems to lead to the restricted area though ![]()
Attaching test webapp sources and assembled WAR.
Roman,
Thanks for all that information! I've attached a patch that should merge the forward parameters properly.
One thing: from what I understand of the spec, those query parameters with non-overridden names should be carried over, so that once the forward has taken place ?name=initialValue&test=othervalue will give you ?name=forwardedValue&test=othervalue. The patch I've attached does this, but when I check your attached webapp in tomcat, I see only ?name=forwardedValue.
Anything to point to which result is correct?