I don't know why there is a problem. THe code which you posted worked perfectly fine for me. I just replace <jsp:include> to <jsp:forward> but I believe that should not pose any problem. I printed the value of the parameter in servlet and I got "+" printed.
I did this on weblogic server. But I'm sure this is not container dependent.
Thanks & Regards, SK
SCJP 5.0, DB2 - 800, DB2 - 803, SCDJWS (On the way)
Joined: Nov 05, 2003
I cannot do jsp:forward as the logic demands jsp:include. Believe me, I'm also surprised by this problem.
The plus sign is considered a place holder for the space character. The jsp:param will encode the URL for you so it shouldn't be a problem (the + will be encoded to %2B).
How are you accessing the values? It looks to me like it is being passed through a decoder once to often The request.getParameter(parameterName) will decode it for you first. Are you doing any other option that also attempts to decode the URL parameter?
Joined: Nov 05, 2003
I'm doing request.getParameter(<parmName>) to get back the param value. What other way value can be decoded? I don't think I'm decoding more than once. I think it's not encoding to start with.
Just to be clear, I'm testing using WebSphere 5.1 test server.
Originally posted by Deb Sadhukhan: I'm doing request.getParameter(<parmName>) to get back the param value. What other way value can be decoded? I don't think I'm decoding more than once.
Not sure if you were passing the value directly throuh URLDecoder.decode() or if you were using some other layer that also decoded. Looks as though not.
Originally posted by Deb Sadhukhan: I think it's not encoding to start with.
That also could be the case ... see below
Originally posted by Deb Sadhukhan: Just to be clear, I'm testing using WebSphere 5.1 test server.
What version of the JSP spec does WebSphere 5.1 support? JSP 2.0 says the jsp:param must URLEncode the parameter, whereas older versions of the spec do not say so. You may have to pass the parameter like:
But this code would break for any server that does support the JSP 2.0 spec because the result would be double encoded...
The parameter names and values speciﬁed should be left unencoded by the page author. The JSP container must encode the parameter names and values using the character encoding from the request object when necessary. For example, if the container chooses to append the parameters to the URL in the dispatchedrequest,boththenamesandvaluesmustbeencodedasperthecontent typeapplication/x-www-form-urlencoded in the HTML speciﬁcation.
So the Tomcat behavior is correct and the Resin behavior (and apparently Websphere) are not.
Originally posted by Bear Bibeault: Section JSP.5.6: So the Tomcat behavior is correct and the Resin behavior (and apparently Websphere) are not.
For JSP 2.0. For JSP 1.2 this behavior was not defined (JSP.4.4-4.6 for in the JSP 1.2 spec for applicable paragraphs). So if the versions of WebSphere and Resin in question don't claim to be JSP 2.0 containers the behavior isn't a bug.