Openfire 3.10.0 Encoding Issue

Openfire Openfire Support
1

After upgrade to 3.10.0 i encountered an issue with character encoding in MUC messages and nicknames.

For example

Client (connected through BOSH) sends:

<body rid='528003' sid='704378c4' xmlns='http://jabber.org/protocol/httpbind' key='c3e31c36f8aa8e290404fd5b1a60e3141fe94dae'>
<message xmlns="jabber:client" type="groupchat" to="uhpo7nlfigk1inhr@conference.xxxxxxxx.com">
<body>Hö hö</body>
</message>
</body>

Server replies with:

<body xmlns='http://jabber.org/protocol/httpbind'>
<message xmlns="jabber:client" type="groupchat" to="zxa5b07ekt6gn6a8@xxxxxxxx.com/uhpo7nlfigk1inhr" from="uhpo7nlfigk1inhr@conference.xxxxxxxx.com/Florian">
<body>H�� h��</body>
</message>
</body>

(See the message text in on line 3)

When i downgrade to 3.9.3 everything works fine without changing anything else on the system.

Openfire runs on Ubuntu 14.04, Java Version: 1.7.0_79 Oracle Corporation – OpenJDK 64-Bit Server VM

Any more info i can provide to track down this issue?

Florian

Message was edited by: Guus der Kinderen

1 Like
2

I find this issue too.I use chinese.

3

Thanks for your feedback. Does anyone else have this problem as well?

4

Thanks for reporting this. I have documented this issue as [OF-918] Character encoding issue in BOSH - Jive Software Open Source

5

I have this problem too. use strophe ,jquery xmpp connect to openfire 3.10 with http-bind.When I sent Chinese message, the received message is garbled. Openfire 3.9.3 and 3.7.1 are ok without changing anything.

6

Thanks for filing the bug!

7

Same issue too. Using openfire 3.10.1 (3.10.2 too) and embedded db + converse.js and russian language.

UPD I’m also noticed that otr messages receiving correct at all, but not regular messages.

8

Anyone know about update for fix this bug?

9

I am having trouble reproducing the issue on Master (3.11.0 Alpha) and on the development branch (3.10.3 Alpha). Can anyone confirm or refute that the problem has disappeared in the latest nightly build?

10

This issue has been addressed in Openfire 3.10.3 as well as in Openfire 3.11.0.

@Florian Sailer provided the following work-around that can be used to stop the issue from occurring in earlier versions of Openfire:

I made some tests and figured out that i can fix the issue by adding “-Dfile.encoding=UTF-8” as option to the JVM. (On Ubuntu i added this to /etc/default/openfire).