User Agent: Mozilla/5.0 (Windows NT 6.0; WOW64) AppleWebKit/535.5 (KHTML, like Gecko) Chrome/16.0.891.0 Safari/535.5 Steps to reproduce: I have seen this bug in beta 7.01 and 8. Those are the only Firefox browsers that support version 8 websockets that I've tried so far. I can observe the server and have witnessed it via Firefox 10.0a1 (which I didn't even know existed). Run the following websocket test page: http://isr.nu/ws/WebSocketTest.htm You have to see the server log information to witness this problem. Actual results: Observable browser behavior is good. UTF-8 and non-UTF-8 characters are sent from the web page and echoed back from the server. They are received by the browser and printed to the web page as expected. The server experiences null pointer exceptions while reading the input stream that did not occur in beta 7.0 and do not occur using Chromium or my non-browser client. Expected results: The server should not experience null pointer exceptions while reading the input stream. This is a new error that was not in beta 7.0. My guesses: Either someone has added a null ending (like with http and the websocket handshake) or perhaps the message payload length is sometimes miscalculated or not properly written according to the version 8 websocket protocol.
Component: General → Networking: WebSockets
Product: Firefox → Core
QA Contact: general → networking.websockets
Not sure what to do. I'm running Beta 8 and cannot repeat the problem. I have also not seen it for days now. On wild speculation, it could even have been the result of someone writing their own client that pretended to be Firefox. Perhaps - any volunteers who want to run the test please do so. I'll keep watch. I'll close this if I don't see another example for a couple more days.
To be clear: the bug you are reporting is that there is a server crash when using Firefox 8 websockets? I'm sympathetic, but you are going to need to provide more complete information on what firefox is doing that is causing the problem and also please comment on whether or not you believe that behavior is compliant with the relevant specifications. Note that, at least with the most recent revisions, receipt of illegal non-utf8 sequences will result in failing the connection.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → INCOMPLETE
No, the server doesn't "crash." All such possible exceptions are caught and dealt with gracefully. As I said above, someone sitting at a web page wouldn't even know that anything was wrong. In my view, the problem could not have occurred if everything worked according to the standard ("the relevant specification"). My guess as to the cause of the problem is given above. Re: failing the connection when such a problem occurs. I'll do that at some point, but thought it might help Mozilla Firefox development by reporting the problem.
I'm now seeing repeated errors from a Firefox version 10.0a1. After successfully receiving and processing the data (for example, the default message in the demo - link above), I get the null pointer exception.
FF 10 is currently 'nightly'. you can get it at nightly.mozilla.org to narrow down your issue. Those entries in your log were probably me trying to repo based on your report, which I could not do.
If what I'm seeing is due to what you're doing, then you have repeated the problem. I realize that it's difficult to analyze with a one-ended view of things. I think I found the reason for another problem today, after working at it most of the day and making a guess or two or three ... I can be reached on Skype: rogerfgay or email@example.com. If you'd like, I'd be willing to zip up a copy of my server so that you could run it. You'd just put it in a directory and use the .bat or .sh to start it. Information will print to the console. (Foreign characters print properly to the terminal only in Unix/Linux, not Windows, but that isn't important.) You'll see for yourself when the exception occurs. You can also run other browsers to confirm that it doesn't ordinarily occur.
Roger, I think it makes more sense for you to explain exactly what is causing the exception in the server code - that is your server afterall. Once you have identified that, we can discuss whether or not that is a problem with firefox. So far all I see is the fact that there is an exception but no indication of what is triggering it.
Messages are successfully handled and then there's something more. Something in addition to the defined data frame. It has no length however, like out.write("") was sent. When the server tries to read it (BufferedReader.readLine()), it throws a null pointer exception. That's an exact description of what's happening. I tried to make it clearer with guesses above about what the browser might be doing to cause it.
I'm returning this to unconfirmed status. The problem description is so simple that perhaps it seems like there should be more. The problem is this and only this: after complete data frames have been completely processed, there's still something in the input stream. The problem has occurred with various versions of Firefox, but recently I've only seen it with v 10.0a1. Other versions, including the versions 7 and 8 that I've been using, do not produce the problem.
Status: RESOLVED → UNCONFIRMED
Resolution: INCOMPLETE → ---
I think the question on status is whether it is confirmed. Roger F. Gay 2011-10-02 08:07:13 PDT above, I reported seeing many examples from a v 10.0a1. Patrick McManus 2011-10-02 08:14:38 PDT, who I assume is trustworthy, immediately responded that he was sending the messages. This would eliminate the possibility that someone built a home-made client that was pretending to be Firefox. The problem has been repeated with confirmation at both ends.
Roger, We'd love to help fix things, especially if FF is causing the problem, but as is, we don't have enough information to know whether the server null ptr exceptions you're seeing are server bugs or something FF is doing. If you've got specific, network packet-level information about how FF is sending spec-incompliant websockets messages, please let us know. Until we get that, it's hard for us to know what's going on.
That's ok. The problem has already been fixed on most versions of Firefox. I bet it'll get sorted out for 10.0a1 as well.
You know .... it'll be tested ...
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago → 6 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.