Search...
FAQs Subscribe
Pie
FAQs
Recent topics Flagged topics Hot topics Best topics
Search...
Search within JSP Search Coderanch
Advance search Google search
Register / Login
thread boost granny advertise on coderanch book review grid polymorphism
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
thread boost meaningless drivel building better world book book review grid advertise on coderanch
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

NullPointerException from request.getParameter(), only for certain URI values

 
Bob Grossman
Ranch Hand
Posts: 83
posted 8 years ago
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
    Send
  • Quote
  • Report post to moderator
I'm using AJAX to pass a string from a Javascript application to a Java server page (JSP) for processing. Here's a snippet of the code:



In very rare (I've found two examples so far) but completely reproducible circumstances, certain values of submissionStr cause responseText to come back empty. The log reveals that a NullPointerException is thrown at the second of these two lines from the JSP page:



The log output shows:



There are a number of features of this problem that are mystifying to me. Why would System.arraycopy() throw a NullPointerException at all, and why would it do it only for very particular values of submissionin the URI? Finally, what can I do to fix the problem?
 
Bear Bibeault
Sheriff
Posts: 67747
173
I like...
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
posted 8 years ago
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
    Send
  • Quote
  • Report post to moderator
I'll just sigh about the misuse of JSPs and trudge onwards...

There is no way on Earth that the NPE is caused by that line of code. What makes you think that it is?

[Asking smart questions] [About Bear] [Books by Bear]

 
Bob Grossman
Ranch Hand
Posts: 83
posted 8 years ago
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
    Send
  • Quote
  • Report post to moderator

Bear Bibeault wrote:There is no way on Earth that the NPE is caused by that line of code. What makes you think that it is?



Well, for one thing the NPE stack trace reports the line in answerframe_jsp.java that throws the exception, and if I look in that file, the reported line is the one I described. For another, if I print to the log immediately before and after that line, the log shows output from before that line, but not after.
 
Bear Bibeault
Sheriff
Posts: 67747
173
I like...
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
posted 8 years ago
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
    Send
  • Quote
  • Report post to moderator


You have checked the Java file for line 409? (Not the JSP file, whose line numbers are meaningless.)

[Asking smart questions] [About Bear] [Books by Bear]

 
Bob Grossman
Ranch Hand
Posts: 83
posted 8 years ago
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
    Send
  • Quote
  • Report post to moderator

Bear Bibeault wrote:

You have checked the Java file for line 409? (Not the JSP file, whose line numbers are meaningless.)



Yes, answerframe_jsp.java, line 409.
 
Bear Bibeault
Sheriff
Posts: 67747
173
I like...
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
posted 8 years ago
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
    Send
  • Quote
  • Report post to moderator
You'll need to provide more context around to code. We'll need to see what's around the failing line (with line numbers would be nice). Providing both the JSP source for the lines as well as the grenade line may help.

And this type of difficult debugging is one of the very many reasons that Java code in JSPs has been obsolete for 15 years. You really shouldn't be writing new JSP pages with scriptlets embedded.

[Asking smart questions] [About Bear] [Books by Bear]

 
Paul Clapham
Marshal
Posts: 28226
95
I like...
Eclipse IDE Firefox Browser MySQL Database
posted 8 years ago
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
    Send
  • Quote
  • Report post to moderator
I wouldn't expect the choice of parameters to be causing bugs in internal SSL code, no matter whether it's in a JSP or not. I think there's something else going on here, but knowing very little about SSL implementations I can't even speculate what.

However if this problem could be reproduced at will using specific parameter names and values I would have to change my mind on that. So far I haven't exactly heard that there's a known repro on this thread.
 
Dave Tolls
Rancher
Posts: 4801
50
posted 8 years ago
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
    Send
  • Quote
  • Report post to moderator
What are the values of toSend that cause the issue?

Print them both in the Javascript on the client as well as use the client browser debug tools to see what the network tab shows as actually being sent.

I'm wondering if something is being garbled somehow.

Next, even if Bear is showing restraint, I have to comment on the munging together of Java stuff inside your Javascript and the use of Java in a JSP page as a whole.
This is poor practice, and seriously dated.
Most of this should be on the server, and the stuff required by the Javascript should be in fields in the HTML...anything than having those snippets there.
 
Bob Grossman
Ranch Hand
Posts: 83
posted 8 years ago
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
    Send
  • Quote
  • Report post to moderator
This phenomenon is completely reproducible on our installation.
I load a chemical drawing into a third-party program.
I press Submit, and the third-party program creates an XML representation of the drawing.
I use AJAX to send the XML to the server for analysis.
When I load a particular structure into the program and submit it, I get the NullPointerException.
If I change the appearance of the structure somewhat, so that some of the coordinates encoded in the XML change, the submission may go through.
I have found two drawings so far that fail to submit. The one whose XML is below is easier to reproduce than the other one; the other one, I always
have to draw in a very particular way to trigger the NPE, and it's hard to do it right every time.

Here is a value for toSend that induces the NullPointerException. Sorry, it contains no return characters, even before it is encoded.



If I convert all instances of >< to >\n< before encoding and submitting, I don't get the NPE.

There's nothing interesting on the JSP page before the line that triggers the NPE. Here it is:



The two included pages, edJava.jsp.h and rxnCondsJava.jsp.h:



When the bug is not triggered, the log says:

INFO: answerJava.jsp.h: about to getParameter().
answerJava.jsp.h: did getParameter().



When the bug is triggered, the log says:

INFO: answerJava.jsp.h: about to getParameter().
java.lang.NullPointerException



I did not experience this problem until we moved to a new, Javascript-based, structure-drawing program. The previous one was a Java applet,
and you probably know more horror stories than I do about Java applets. One difference between the previous and the current structure-drawing
programs is that the current one does not put return characters after each XML element, whereas the previous one did. If I add return
characters to the XML above that causes the NPE, I do not get an NPE. But that doesn't mean that I would never get an NPE with some
different XML that did contain return characters.

Finally, I appreciate your disparagement of the code, but I am not writing it from scratch, and it does indeed date back about 15 years.
I recognize that it could be written more efficiently and in a more maintenance-friendly manner, but I am not in a position to rewrite it.
I am just trying to figure out why on very rare occasions, the code fails.
 
Paul Clapham
Marshal
Posts: 28226
95
I like...
Eclipse IDE Firefox Browser MySQL Database
posted 8 years ago
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
    Send
  • Quote
  • Report post to moderator

Bob Grossman wrote:If I convert all instances of >< to >\n< before encoding and submitting, I don't get the NPE.



I think the forum software has changed what you entered, because of the markup characters around it. Would you like to clarify?

Also it seems to me that data that large is often sent via the POST method rather than the GET method, because a lot of systems have limits (not necessarily well-documented) to the length of a GET URL they can handle. I don't know if that's a change you can make or not. Using POST would eliminate the requirement for URL-encoding, too.
 
Bob Grossman
Ranch Hand
Posts: 83
posted 8 years ago
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
    Send
  • Quote
  • Report post to moderator
I don't think the forum changed what I wrote. In XML without return characters, there are many instances of ><, that is, a greater than sign to close one element, and a less than sign to open the next element. I can insert a return character after each element by doing a global replacement of >< with >\n<, like this:



And when I do that, the new string does not trigger the NPE. As I said, this is a bizarre bug. Seemingly trivial changes in the URI make a difference in whether the NPE is triggered.

As for GET vs. POST, we already use POST. See line 11 of the first block of code in my very first post in this topic.
 
Stefan Evans
Bartender
Posts: 1845
10
posted 8 years ago
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
    Send
  • Quote
  • Report post to moderator
Hi Bob,

Paul suggested using POST rather than GET, so that you don't need to encode your url encoding.
Your response was that you were using POST - which you are. The parameters are sent via xmlHttp.send() on line 16.

So that would suggest you don't need to have the call to encodeURIComponent on line 2 of your source. Maybe that might be a source of trouble?
If the send method will encode your parameters for you, then encoding things twice might be a potential issue :-)


My suggestion - try and take the JSP part out of the equation.
Refactor the JSP expressions out of this javascript fragment into variables that you use in the javascript.
Can you reproduce this issue with 'hard-coded' values?
That will mean you can then unit test just the javascript section without needing to actually run it as a JSP.


cheers,
Stefan
 
Paul Clapham
Marshal
Posts: 28226
95
I like...
Eclipse IDE Firefox Browser MySQL Database
posted 8 years ago
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
    Send
  • Quote
  • Report post to moderator
I just have two comments to make:

First, you seem to have a workaround which prevents the NPEs from occurring, so maybe you should just go with that.

Second, no matter how malformed an HTML request might be it still shouldn't cause errors in the SSL layer of the server code. So my feeling is that either there's an error in the way Tomcat sets up its connection via SSL, or there's an error in Oracle's SSL code. I would lean towards the latter but only slightly; however if there errors in SSL processing there could be security exploits associated with that error. I'd look into that more closely, for example maybe there's something not quite right about the security certificate you're using to support SSL. Or something like that. Details of just what you should look into are beyond my competence and I'd suggest getting somebody experienced in security to review the situation.
 
Bob Grossman
Ranch Hand
Posts: 83
posted 8 years ago
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
    Send
  • Quote
  • Report post to moderator

Paul Clapham wrote:
First, you seem to have a workaround which prevents the NPEs from occurring, so maybe you should just go with that.



I would agree, except that because I have no idea what is triggering the error, the workaround may work for this response, but then cause another response that would ordinarily go through, not to go through! So I'm not happy with my workaround.

 
Bob Grossman
Ranch Hand
Posts: 83
posted 8 years ago
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
    Send
  • Quote
  • Report post to moderator

Stefan Evans wrote:Hi Bob,

Paul suggested using POST rather than GET, so that you don't need to encode your url encoding.
Your response was that you were using POST - which you are. The parameters are sent via xmlHttp.send() on line 16.

So that would suggest you don't need to have the call to encodeURIComponent on line 2 of your source. Maybe that might be a source of trouble?
If the send method will encode your parameters for you, then encoding things twice might be a potential issue :-)



Thanks for your suggestion. I don't see how I can forego encoding. The response that I am sending definitely contains = symbols and may contain & symbols; if I don't encode it, I imagine that the server will try to split up the one parameter into multiple ones, won't it? As a simplified example, if I want to send the value "a&b=c" for parameter p, and I don't encode, I'll be sending "p=a&b=c". and won't the server interpret that as parameter p having a value of "a" and parameter b having a value of "c"?

As fo the rest of your suggestion, I don't understand what I would learn from your suggestion. I know exactly where the NPE occurs, and it doesn't have anything to do with the Javascript.
 
Bob Grossman
Ranch Hand
Posts: 83
posted 8 years ago
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
    Send
  • Quote
  • Report post to moderator
For those of you following this thread: We recently switched from http to https. Under https, the browser and server use certain SSL cipher protocols to communicate. Apparently, there's a bug associated with the AES ciphers. Changing the server configuration to remove AES/GCM from the list of acceptable ciphers eliminated the problem.

We also found that among the Mac browsers, although Safari and Chrome chose the AES protocol if it was available, and thereby manifested the bug, Firefox did not.

I still don't know what property of a URI causes the AES bug to manifest, but I guess I don't need to know anymore.

Thanks for your willingness to help.
 
Consider Paul's rocket mass heater.
reply
reply
    Bookmark Topic Watch Topic
  • New Topic
Boost this thread!
Similar Threads
More...