0004880: WebSocket decoding does not work correctly

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.

Issue History
Date Modified	Username	Field	Change
11-28-11 13:43	ihristov	New Issue
11-28-11 14:25	ferg	Note Added: 0005637
11-29-11 00:02	ihristov	Note Added: 0005640
11-29-11 10:20	ferg	Note Added: 0005641
11-29-11 13:23	ihristov	Note Added: 0005642
02-16-12 14:09	ferg	Assigned To	=> ferg
02-16-12 14:09	ferg	Status	new => closed
02-16-12 14:09	ferg	Resolution	open => fixed
02-16-12 14:09	ferg	Fixed in Version	=> 4.0.25

Relationships