Mudlet not respecting user-selected server data encoding setting

Bug #1959465 reported by Mike VanCleave
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
mudlet (Ubuntu)
New
Undecided
Unassigned

Bug Description

When connecting to MUME with Force CHARSET negotiation enabled (box NOT checked under Special settings), and UTF-8 selected for Server data encoding in general settings, encoding is changed to ISO 8859-1 during negotiation with the server. It appears that, during this negotiation, the server offers several options, and Mudlet is choosing the first compatible option in the list (ISO 8859-1) rather than the user selected preference (UTF-8), which is also available.

I was able to use UTF-8 by turning Force CHARSET negotiation off and manually setting UTF-8 in the MUD using the command line.

I think the expected behavior (at least the behavior I expected) is that, if I have Force CHARSET negotiation on, and have chosen a particular encoding, Mudlet would enforce that encoding with the server, if it is available.

Here are the packets that are exchanged during the negotiation:

From Mud to MudletP:

0000 a8 a1 59 24 c5 05 60 5f 8d 05 ba f2 08 00 45 00 ..Y$..`_......E.
0010 00 6f d3 f7 40 00 2f 06 13 5e c1 86 da 62 c0 a8 .o..@./..^...b..
0020 07 a2 10 92 94 32 78 00 8c b4 7c ca 98 fc 80 18 .....2x...|.....
0030 01 fc a2 12 00 00 01 01 08 0a d7 7b b5 a4 f1 35 ...........{...5
0040 5c a1 ff fa 18 01 ff f0 ff fa 2a 01 3b 49 53 4f \.........*.;ISO
0050 5f 38 38 35 39 2d 31 3a 31 39 38 37 3b 49 53 4f _8859-1:1987;ISO
0060 2d 38 38 35 39 2d 31 3b 55 54 46 2d 38 3b 55 53 -8859-1;UTF-8;US
0070 2d 41 53 43 49 49 ff f0 ff fa 56 ff f0 -ASCII....V..

Response to Mud from Mudlet:

0000 60 5f 8d 05 ba f2 a8 a1 59 24 c5 05 08 00 45 00 `_......Y$....E.
0010 00 57 1f 0b 40 00 40 06 b7 62 c0 a8 07 a2 c1 86 .W..@.@..b......
0020 da 62 94 32 10 92 7c ca 98 fc 78 00 8c ef 80 18 .b.2..|...x.....
0030 01 f5 64 7d 00 00 01 01 08 0a f1 35 5d 93 d7 7b ..d}.......5]..{
0040 b5 a4 ff fa 18 00 4d 75 64 6c 65 74 20 34 2e 31 ......Mudlet 4.1
0050 34 2e 31 ff f0 ff fa 2a 02 49 53 4f 2d 38 38 35 4.1....*.ISO-885
0060 39 2d 31 ff f0 9-1..

Revision history for this message
Vadim Peretokin (vperetokin) wrote :

Hi!

> When connecting to MUME with Force CHARSET negotiation enabled (box NOT checked under Special settings)

There is no 'force charset negotiation on' option, just an option to turn it off which is why I think you're confused.

The way it works is: you can either allow the server to set the encoding, or you want to choose it yourself in which case you don't allow it.

It's unfortunate that MUME is giving preference to ISO 8859-1 - it should give preference to UTF-8.

I hope that helps!

Revision history for this message
Mike VanCleave (mvancleave) wrote :

Thank you for the response.

I do not think I am confused. Please note in my original report: "with Force CHARSET negotiation enabled (box NOT checked under Special settings)," so I understand how the "Force CHARSET negotiation off" checkbox works.

I still assert that the behavior described in the report is inconsistent with reasonable user expectations.

If the user wants Mudlet to force CHARSET negotiation, they would do the following:

 - select their desired CHARSET from the dropdown under General/Server data encoding:
 - ensure that the "Force CHARSET negotiation off" box under Special Options is NOT checked
 - connect to their mud

Expected behavior:

Mudlet would negotiate with the server and connect using the user-selected encoding, if available, regardless of the order in which the mud server presents the available options.

Experienced behavior:

Mudlet connects to the server using the first encoding offered by the server even though the user-selected encoding was available. Mudlet changes the selection in the Server data encoding dropdown, overriding user input, and gives no indication to the user that the connection is not using the user-selected CHARSET (unless the user opens Preferences and checks).

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.