• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

JSP rookie, here -- Stoopid question, I'm sure...

OhioDude

Diamond Member
I'm writing a string value into a form field in a javascript function that is called from a hyperlink click. The form is submitted to a jsp page. The function is as follows:

function doSubmit(letter, Title)
{
document.forms["SIMPLEFORM"].JSPPAGE.value="ecommerce/jsp/ecguestcatclass.jsp";
document.forms["SIMPLEFORM"].CNAME.value=letter;
document.forms["SIMPLEFORM"].CTITLE.value=Title;
document.forms["SIMPLEFORM"].CWORKFILE.value=parent.parent.G_SESSIONID;
document.forms["SIMPLEFORM"].submit();
return false;
}


Let's say the hyperlink that is clicked calls the function as follows:

doSubmit("A", "The Page Title / Heading");

When I write what's in CTITLE to an html page from within my jsp page as follows:

out.print(request.getParameter("CTITLE"));

It prints the string as "The+Page+Title+%2F+Heading".

Where did the "+"s and the "%2F" come from? How can I get rid of them?

😕
 
I've barely done any JSP... but it sort of looks like the text got encoded. The spaces were replaced by +'s and the / replaced by %2F. Normally, when you encode a URL, special characters like spaces are coverted to %xx with xx being a number. For example, spaces are normally converted to %20.

Try replacing all the +'s with spaces and decoding the URL before printing it.

http://www.theserverside.com/d...ead.tss?thread_id=6837

There's some example code farther down for decoding.

For replacing the spaces, assign the CTITLE value to a string and use the replace method.

String foo = request.getParameter("CTITLE");
foo.Replace('+', ' ');

Or something like that.
 
Somewhere within the jsp/servlet api there should be URLEncode and URLDecode functions, although I can't seem to find them right now 😕 But I don't think you want to try to be fixing this yourself, it'd be too messy.

However, this should not be necessary as this doesn't normally happen. I'd wager that the form that this stuff is a part of has GET as it's method. That just means that all the form parameters will be written into the request url (and hence causing your problem). If you can, change the method of the form to POST. This is the way things are normally done and should solve your problem. There should be no difference on the server side which method you use (except for the apparent url encoding of parameters).
 
Update: If you must decode this yourself, check out java.net.URLDecoder and the corresponding URLEncoder. Just be careful you don't run that on non-encoded strings as it may corrupt stuff.
 
Thanks for the replies, guys!

Kamper: The method for the form was GET. Changed it to POST but I still get the same thing. :confused

I'm going to look into the URLDecoder class...
 
Hmm, I just whipped up a little test page that submits either by post or get and both worked properly (no url encoding). I also tried assigning the value with javascript, same deal.

There are a couple things I would try for debugging purposes before resorting to a url decode (you have to know why this happens or it might unexpectedly go away).

When you submit the form with GET the CTITLE parameter should show up in the url of the page. Can you post that value? It might be double escaped.
Also, put an alert() statement right before the call to submit() to tell you what the value of the textbox is (or is this a hidden field?).
Then, check out the actual submission that crosses the network. LiveHTTPHeaders for firefox would help but we might get confused by how many times things are escaped. Ethereal, if you have it handy, would give a more definitive answer and would allow us to see the request body for a POST request.

<edit> One more thing: if you get a look at the http headers of the request can you post the value of the Content-Type field? </edit>

If things make sense that far, then it's a server side problem which might not be as easy to debug. What platform are you using?
 
Kamper --

First, thanks for all your help. 🙂

To answer some of your questions, the host platform is AIX 4.3. The webserver is Apache 1.3 and the Java runtime looks like version 1.1.8.

All fields on the form are hidden. An alert() displaying the value in the CTITLE form field immediately prior to the submit() displays the expected values, i.e, the unencoded values.

I think I discovered the problem after looking at my http logs. This JSP page (ecguestcatclass.jsp) submits to another JSP page (ecruncobol.jsp) that then submits the same information using GET to a third-party product called NetExpress that allows legacy COBOL code to be executed from a webpage. NetExpress then sends the information back to this page (ecguestcatclass.jsp). It would appear that CTITLE is being encoded by ecruncobol.jsp when it uses GET to submit the form values to the NetExpress product. (Why ecguestcatclass.jsp doesn't just submit to NetExpress itself using POST, I have no idea. I didn't write the application... I'm just modding it for the customer.)

I'm hesitant to change the form's submit method in ecruncobol.jsp to POST for fear of what I might break elsewhere in the application. (This is a complete B2B CRM application.) It looks like I might be stuck just decoding CTITLE within eccatclass.jsp.
 
In that case decoding is fine. The important thing is that you know why and where it is being encoded so that you don't try to decode something when it shouldn't be.

Are you sure you're running the 1.1.8 runtime? That's really freakin' old. I think URLDecoder was only added in 1.4. If it isn't available in your sdk then I would suggest downloading the 1.4 api and copying that method exactly into a class of your own. That will save a tonne of work and will ensure that it works properly.
 
Back
Top