Mantis - Resin
Viewing Issue Advanced Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4880 block always 11-28-11 13:43 02-16-12 14:09
Reporter: ihristov Platform:  
Assigned To: ferg OS:  
Priority: normal OS Version:  
Status: closed Product Version: 4.0.24  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 4.0.25  
Summary: 0004880: WebSocket decoding does not work correctly
Description: The websocket data sent to the resin server doesn't get decoded correctly.
Steps To Reproduce:
Additional Information: Seems like you don't appreciate my feedback, since this is the third issue for the same problem (already quite well described in issue 0004818 and 0004873). Since, I can't reply to the closed issue 0004873, I am creating this. And the error that you are searching for is that the data does NOT get decoded correctly when reading from the WebSocket. However, if you intentionally encode the data over the WebSocket with ISO-8859-1 you will be surprised to see that everything works fine.
Relationships
Attached Files:

Notes
(0005637)
ferg   
11-28-11 14:25   
The bug 0004818 was duplicated, and fixed in 4.0.24.

If you are still seeing a similar problem in 4.0.24, that is a new bug report, but specific details, again, for the methods that are being called (and possibly the UTF-8 characters sent and client), would be important to the bug report.

Bug 0004873 is irrelevant and not a bug report.
(0005640)
ihristov   
11-29-11 00:02   
Yes, I am still seeing a similar problem (if not the same problem) with version 4.0.24. Again, just like mentioned in http://bugs.caucho.com/view.php?id=4818 [^] if you provide an implementation of com.caucho.websocket.WebSocketListener and use the public void onReadText(WebSocketContext context, Reader is) throws IOException; method you will be badly surprised that the encoding does not work. You can test this erroneous decoding problem by sending messages containing all characters of the English alphabet plus digits (0-9) and symbols (like +,-,",*,%,&,/,(,),=,?,;,.,:,{,},[,],!,$,\,<,>,,,_). If you intentionally encode the data over the WebSocket with ISO-8859-1 you will see that everything works fine.
As for the issue 0004873, if you don't like it maybe you should provide a template for your understanding of an issue.
(0005641)
ferg   
11-29-11 10:20   
Your description of the failing message doesn't make sense.

The characters of the English alphabet, digits, and symbols are all US-ASCII, which have an identical encoding for both ISO-8859-1 and UTF-8. (All unicode below 0x80 are identical for both ISO-8859-1 and UTF-8.) So your suggested test message is identical for both encodings.

The difference between ISO-8859-1 and UTF-8 shows up for code points above 0x80. For example, the English Pound symbol is 0xa3 in ISO-8859-1, but 0xc2 0xa3 in UTF-8.

In WebSocket, the 0xa3 pound symbol in a text encoding is

  0x81 0x02 0xc2 0xa3

Note that the length is 2 in WebSocket because there are two encoded bytes, not one.

If you have a specific WebSocket message that fails, it would be very helpful to have the exact byte sequence. Since you are changing the encoding of the client (incorrectly), I assume you're writing the client yourself. If not, it would be very helpful to know which WebSocket client you are using.
(0005642)
ihristov   
11-29-11 13:23   
I agree with your point and I admit that it does not make sense. As I said, you can try it by sending a message encoded in UTF-8 and in ISO-8859-1 and see for yourself. You don't have to believe me. On my machine I have the French and German layout in addition to the English but I have not used any of the special characters in any of those languages for constructing the message. Unfortunately, I cannot provide you with the message, but as I said, it only includes characters from the English alphabet. The client I've used is Unitt (http://code.google.com/p/unitt/, [^] see also issue http://bugs.caucho.com/view.php?id=4818), [^] presently there is bug in the client's code which does not set the Sec-WebSocket-Key header field correctly to a 16 bytes value, so make sure you set this field manually (you can do this easily). Furthermore you have to hack the client so that it encodes the messages in ISO-8859-1 but I guess that will be an easy job for you.