Server not writing unicode names correctly (b/c of utf8?)

Need help with FileZilla Server? Something does not work as expected? In this forum you may find an answer.

Moderator: Project members

Message
Author
User avatar
boco
Contributor
Posts: 26913
Joined: 2006-05-01 03:28
Location: Germany

#31 Post by boco » 2006-06-21 23:04

@marco: For Firefox, use menu command

Code: Select all

View-Character Encoding-Unicode (UTF8)
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Code: Select all

[ ] Pure Unicode mode                             <-- currently, the server works in this mode
[X] Use Local Encoding until OPTS UTF8 ON is sent <-- this would be my choice
[ ] Use Local Encoding only                       <-- 0.9.14a and below
Is it really not possible to behave this way? The OPTS UTF8 OFF is great, but many older clients have either no option to enter raw commands or don't even get to the point where they could.

The server should (in my oppinion) default to the older (more compatible) Local Encoding method, then switching to the advanced method (UTF-8 ) upon request. All UTF8-aware clients still support the older method but not vice versa.

boco

twu2
425 Can't open data connection
Posts: 45
Joined: 2005-02-26 16:54

#32 Post by twu2 » 2006-06-22 05:17

here is the patch for filezilla server to allow user to disable UTF8 by default, and enable UTF8 support until receive OPTS UTF8 ON:

Code: Select all

diff -Nur source/ControlSocket.cpp source.patch/ControlSocket.cpp
--- source/ControlSocket.cpp	Tue May 30 22:06:00 2006
+++ source.patch/ControlSocket.cpp	Thu Jun 22 12:10:13 2006
@@ -84,7 +84,10 @@
 	m_antiHammeringWaitTime = 0;
 	m_bProtP = false;
 
-	m_useUTF8 = true;
+	if (m_pOwner->m_pOptions->GetOptionVal(OPTION_UTF8_OFF))
+		m_useUTF8 = false;
+	else
+		m_useUTF8 = true;
 }
 
 CControlSocket::~CControlSocket()
diff -Nur source/OptionTypes.h source.patch/OptionTypes.h
--- source/OptionTypes.h	Thu May 11 20:33:00 2006
+++ source.patch/OptionTypes.h	Thu Jun 22 12:31:11 2006
@@ -78,8 +78,9 @@
 #define OPTION_SHAREDWRITE 52
 #define OPTION_NOEXTERNALIPONLOCAL 53
 #define OPTION_ACTIVE_IGNORELOCAL 54
+#define OPTION_UTF8_OFF 55
 
-#define OPTIONS_NUM 54
+#define OPTIONS_NUM 55
 
 #define CONST_WELCOMEMESSAGE_LINESIZE 75
 
@@ -148,7 +149,8 @@
 												_T("SSL Key Password"),			0,	FALSE,
 												_T("Allow shared write"),		1,	FALSE,
 												_T("No External IP On Local"),	1,	FALSE,
-												_T("Active ignore local"),		1,	FALSE
+												_T("Active ignore local"),		1,	FALSE,
+												_T("UTF8 OFF by default"),		1,	FALSE
 											};
 
 #endif // OPTION_TYPES_INCLUDED
diff -Nur source/Options.cpp source.patch/Options.cpp
--- source/Options.cpp	Sat Apr 29 22:20:12 2006
+++ source.patch/Options.cpp	Thu Jun 22 12:08:20 2006
@@ -231,6 +231,10 @@
 		if (value < 0 || value > 1)
 			value = 0;
 		break;
+	case OPTION_UTF8_OFF:
+		if (value < 0 || value > 1)
+			value = 0;
+		break;
 	}
 
 	Init();
@@ -731,6 +735,9 @@
 				break;
 			case OPTION_ACTIVE_IGNORELOCAL:
 				m_sOptionsCache[nOptionID-1].value = 1;
+				break;
+			case OPTION_UTF8_OFF:
+				m_sOptionsCache[nOptionID-1].value = 0;
 				break;
 			default:
 				m_sOptionsCache[nOptionID-1].value = 0;
diff -Nur source/interface/FileZilla server.rc source.patch/interface/FileZilla server.rc
--- source/interface/FileZilla server.rc	Sun May 28 22:02:46 2006
+++ source.patch/interface/FileZilla server.rc	Thu Jun 22 12:04:00 2006
@@ -552,11 +552,11 @@
     LTEXT           "Static",IDC_TEXT,7,7,215,38
 END
 
-IDD_OPTIONS_GENERAL DIALOGEX 0, 0, 286, 208
+IDD_OPTIONS_GENERAL DIALOGEX 0, 0, 286, 222
 STYLE DS_SETFONT | DS_FIXEDSYS | DS_CONTROL | WS_CHILD
 FONT 8, "MS Shell Dlg", 0, 0, 0x1
 BEGIN
-    GROUPBOX        "Connection settings",IDC_STATIC,7,7,272,48
+    GROUPBOX        "Connection settings",IDC_STATIC,7,7,272,66
     LTEXT           "&Listen on these ports:",IDC_STATIC,13,20,76,8
     EDITTEXT        IDC_PORT,89,17,89,14,ES_AUTOHSCROLL
     LTEXT           "List of ports between 1 and 65535.",IDC_STATIC,184,15,
@@ -564,26 +564,28 @@
     LTEXT           "&Max. number of users:",IDC_STATIC,13,38,73,8
     EDITTEXT        IDC_MAXUSERS,89,35,40,14,ES_AUTOHSCROLL | ES_NUMBER
     LTEXT           "(0 for unlimited users)",IDC_STATIC,133,38,67,8
-    GROUPBOX        "Performance settings",IDC_STATIC,7,60,272,57
-    LTEXT           "&Number of Threads:",IDC_STATIC,14,75,64,8
-    EDITTEXT        IDC_THREADNUM,89,73,40,14,ES_AUTOHSCROLL | ES_NUMBER
+    CONTROL         "UTF8 OFF by default.",IDC_UTF8_OFF,"Button",
+                    BS_AUTOCHECKBOX | WS_TABSTOP,15,55,75,9
+    GROUPBOX        "Performance settings",IDC_STATIC,7,77,272,57
+    LTEXT           "&Number of Threads:",IDC_STATIC,14,94,64,8
+    EDITTEXT        IDC_THREADNUM,89,92,40,14,ES_AUTOHSCROLL | ES_NUMBER
     LTEXT           "This value should be a multiple of the number of processors installed on your system. Increase this value if your server is under heavy load.",
-                    IDC_STATIC,135,71,137,33
-    GROUPBOX        "Timeout settings",IDC_STATIC,7,123,272,78,0,
+                    IDC_STATIC,135,90,137,33
+    GROUPBOX        "Timeout settings",IDC_STATIC,7,137,272,78,0,
                     WS_EX_TRANSPARENT
-    LTEXT           "&Connections timeout:",IDC_STATIC,13,136,69,8
-    EDITTEXT        IDC_TIMEOUT,88,133,41,14,ES_AUTOHSCROLL | ES_NUMBER
+    LTEXT           "&Connections timeout:",IDC_STATIC,13,149,69,8
+    EDITTEXT        IDC_TIMEOUT,88,146,41,14,ES_AUTOHSCROLL | ES_NUMBER
     LTEXT           "in seconds (1-9999, 0 for no timeout)",IDC_STATIC,137,
-                    136,135,8
-    LTEXT           "No &Transfer timeout:",IDC_STATIC,13,155,68,8
-    EDITTEXT        IDC_TRANSFERTIMEOUT,88,152,41,14,ES_AUTOHSCROLL | 
+                    149,135,8
+    LTEXT           "No &Transfer timeout:",IDC_STATIC,13,168,68,8
+    EDITTEXT        IDC_TRANSFERTIMEOUT,88,165,41,14,ES_AUTOHSCROLL | 
                     ES_NUMBER
     LTEXT           "in seconds (1-9999, 0 for no timeout). This value specifies the time a user has to initiate a file transfer.",
-                    IDC_STATIC,137,148,135,26
-    LTEXT           "L&ogin timeout:",IDC_STATIC,13,184,45,8
-    EDITTEXT        IDC_LOGINTIMEOUT,88,180,41,14,ES_AUTOHSCROLL | ES_NUMBER
+                    IDC_STATIC,137,161,135,26
+    LTEXT           "L&ogin timeout:",IDC_STATIC,13,197,45,8
+    EDITTEXT        IDC_LOGINTIMEOUT,88,193,41,14,ES_AUTOHSCROLL | ES_NUMBER
     LTEXT           "in seconds (1-9999, 0 for no timeout). This value specifies the time in which a new user has to login.",
-                    IDC_STATIC,137,175,136,26
+                    IDC_STATIC,137,188,136,26
 END
 
 IDD_OFFLINEASK DIALOG  0, 0, 147, 89
diff -Nur source/interface/OptionsGeneralPage.cpp source.patch/interface/OptionsGeneralPage.cpp
--- source/interface/OptionsGeneralPage.cpp	Thu Mar 24 18:42:14 2005
+++ source.patch/interface/OptionsGeneralPage.cpp	Thu Jun 22 11:58:23 2006
@@ -42,6 +42,7 @@
 	//{{AFX_DATA_INIT(COptionsGeneralPage)
 	m_MaxUsers = _T("");
 	m_Port = _T("");
+	m_bUTF8OFF = FALSE;
 	m_Threadnum = _T("");
 	m_Timeout = _T("");
 	m_NoTransferTimeout = _T("");
@@ -57,6 +58,7 @@
 	DDX_Text(pDX, IDC_MAXUSERS, m_MaxUsers);
 	DDV_MaxChars(pDX, m_MaxUsers, 9);
 	DDX_Text(pDX, IDC_PORT, m_Port);
+	DDX_Check(pDX, IDC_UTF8_OFF, m_bUTF8OFF);
 	DDX_Text(pDX, IDC_THREADNUM, m_Threadnum);
 	DDV_MaxChars(pDX, m_Threadnum, 2);
 	DDX_Text(pDX, IDC_TIMEOUT, m_Timeout);
@@ -145,6 +147,7 @@
 void COptionsGeneralPage::LoadData()
 {
 	m_Port = m_pOptionsDlg->GetOption(OPTION_SERVERPORT);	
+	m_bUTF8OFF = m_pOptionsDlg->GetOptionVal(OPTION_UTF8_OFF) != 0;	
 	m_Threadnum.Format("%d", m_pOptionsDlg->GetOptionVal(OPTION_THREADNUM));	
 	m_MaxUsers.Format("%d", m_pOptionsDlg->GetOptionVal(OPTION_MAXUSERS));	
 	m_Timeout.Format("%d", m_pOptionsDlg->GetOptionVal(OPTION_TIMEOUT));	
@@ -155,9 +158,10 @@
 void COptionsGeneralPage::SaveData()
 {
 	m_pOptionsDlg->SetOption(OPTION_SERVERPORT, m_Port);
+	m_pOptionsDlg->SetOption(OPTION_UTF8_OFF, m_bUTF8OFF);
 	m_pOptionsDlg->SetOption(OPTION_THREADNUM, atoi(m_Threadnum));
 	m_pOptionsDlg->SetOption(OPTION_MAXUSERS, atoi(m_MaxUsers));
 	m_pOptionsDlg->SetOption(OPTION_TIMEOUT, atoi(m_Timeout));
 	m_pOptionsDlg->SetOption(OPTION_NOTRANSFERTIMEOUT, atoi(m_NoTransferTimeout));
 	m_pOptionsDlg->SetOption(OPTION_LOGINTIMEOUT, atoi(m_LoginTimeout));
-}
\ No newline at end of file
+}
diff -Nur source/interface/OptionsGeneralPage.h source.patch/interface/OptionsGeneralPage.h
--- source/interface/OptionsGeneralPage.h	Sun Jun  6 18:35:46 2004
+++ source.patch/interface/OptionsGeneralPage.h	Thu Jun 22 11:55:52 2006
@@ -66,6 +66,9 @@
 		// HINWEIS: Der Klassen-Assistent f�gt hier Member-Funktionen ein
 	//}}AFX_MSG
 	DECLARE_MESSAGE_MAP()
+
+public:
+	BOOL m_bUTF8OFF;
 };
 
 //{{AFX_INSERT_LOCATION}}
diff -Nur source/interface/resource.h source.patch/interface/resource.h
--- source/interface/resource.h	Wed Mar  8 18:02:38 2006
+++ source.patch/interface/resource.h	Thu Jun 22 11:54:21 2006
@@ -257,6 +257,7 @@
 #define IDC_SHAREWRITE                  1197
 #define IDC_CHECK1                      1198
 #define IDC_ACTIVE_IGNORELOCAL          1199
+#define IDC_UTF8_OFF			1200
 #define ID_ACTIVE                       32768
 #define ID_DIRMENU_ADD                  32769
 #define ID_DIRMENU_REMOVE               32770
@@ -304,7 +305,7 @@
 #define _APS_3D_CONTROLS                     1
 #define _APS_NEXT_RESOURCE_VALUE        167
 #define _APS_NEXT_COMMAND_VALUE         32805
-#define _APS_NEXT_CONTROL_VALUE         1200
+#define _APS_NEXT_CONTROL_VALUE         1201
 #define _APS_NEXT_SYMED_VALUE           1228
 #endif
 #endif
and my build for this patch: http://www.teatime.com.tw/~tommy/FileZillaServer.zip
my adsl has some problem now, use this one if above one is not available:
http://fcy.teatime.com.tw/FileZillaServer.zip

also, we need to modify filezilla to send OPTS UTF8 ON for FileZilla server:

Code: Select all

diff -Nur source/FtpControlSocket.cpp source.patch/FtpControlSocket.cpp
--- source/FtpControlSocket.cpp	Fri May 26 14:24:30 2006
+++ source.patch/FtpControlSocket.cpp	Thu Jun 22 12:39:06 2006
@@ -527,7 +527,7 @@
 				m_Operation.nOpState = CONNECT_CLNT;
 			return;
 		}
-		if (m_bUTF8 && !m_isFileZilla)
+		if (m_bUTF8)
 		{
 			// Handle servers that disobey RFC 2640 that have UTF8 in the FEAT
 			// response but do not use UTF8 unless OPTS UTF8 ON gets send.
here is my filezilla build include above patch and sftp utf-8 support: http://www.teatime.com.tw/~tommy/filezilla.zip
my adsl has some problem now, use this one if above one is not available:
http://fcy.teatime.com.tw/filezilla.zip
Last edited by twu2 on 2006-06-22 06:04, edited 1 time in total.

twu2
425 Can't open data connection
Posts: 45
Joined: 2005-02-26 16:54

#33 Post by twu2 » 2006-06-22 05:22

another problem: Because FileZilla Server Interface program is not a unicode program, still be a ANSI program, so we can't setup the shared folder in unicode. Is it possible to convert this program to unicode also?

User avatar
botg
Site Admin
Posts: 35508
Joined: 2004-02-23 20:49
First name: Tim
Last name: Kosse

#34 Post by botg » 2006-06-22 08:24

I'm sorry, but your patch violates two RFCs. Obviously RFC 2640 and even RFC 959 if local charset is not US-Ascii compatible (Big5 for example).

twu2
425 Can't open data connection
Posts: 45
Joined: 2005-02-26 16:54

#35 Post by twu2 » 2006-06-22 10:33

yes, it violates RFC-2640. or maybe we can also add a check for OPTION_UTF8_OFF to decide send 'UTF8' in FEAT or not.
If OPTION_UTF8_OFF is false, yes, FZ server will send UTF8 in FEAT as RFC-2640 said.
If OPTION_UTF8_OFF is true, don't sent UTF8 in FEAT.

I think RFC-2640 didn't consider the compatible for old programs.
Before we've RFC-2640, ftp server and ftp client didn't transfer the name use UTF-8, they always use local ansi string.
Now RFC-2640 said, when a server support RFC-2640, it will show UTF8 in FEAT, then client will receive UTF-8 encoding filename, should send UTF-8 encoding filename to server, but, for a non-RFC-2640 client, it won't know UTF-8.

So if everything following RFC-2640, a RFC-2640 ftp server will only accept a RFC-2640 ftp client only, it will reject any non-RFC-2640 ftp client, because such client don't know UTF-8.

For compatible, like other ftp server/client, they didn't follow RFC-2640 100%, because for a 100% RFC-2640 ftp server, only 100% RFC-2640 ftp client can communicate if the use non-english filename. most of them just make some modify for RFC-2640, they won't run in UTF-8 mode at beginning like RFC-2640, they choose to run in non-UTF-8 mode, so they still can communicate with the client without RFC-2640 support, and keep to support UTF-8 unitl client send 'OPTS UTF8 ON' command, then change to UTF-8 mode support like RFC-2640.

I think this will be a better solution for us (CJK users) than a totally RFC-2640 one. To us, a 100% RFC-2640 ftp server will only accept RFC-2640 client, but a modify RFC-2640 ftp server can accept both RFC-2640 client and non-RFC-2640 client.

Add this option, user can choose the keep in 100% RFC-2640 ftp server or a non-100%-RFC-2640 ftp server but meet their requirements.

Yes, transfer non-US-ASCII filename like BIG5 encoding will violate RFC 959, but, for us (Chinese, from Taiwan and Hongkong, who use BIG5 encoding), we already use BIG5 for a long time, and almost all ftp server and client allow us to transfer BIG5 filename directly.

User avatar
boco
Contributor
Posts: 26913
Joined: 2006-05-01 03:28
Location: Germany

#36 Post by boco » 2006-06-22 12:01

@twu2 /signed

I'd be willing to "violate" any RFC to be able to use FZS with ANY client, and not to have TWO FZS on my computer.

Will try your solution ASAP, maybe you could make an independent project?

boco

User avatar
botg
Site Admin
Posts: 35508
Joined: 2004-02-23 20:49
First name: Tim
Last name: Kosse

#37 Post by botg » 2006-06-22 18:32

If specifications are not obeyed, one ends up with something like Internet Explorer. Pages "optimized" for IE causing huge problems with all other brothers.
This is why FileZilla Server will follow the specification as closely as possible.
twu2 wrote:I think RFC-2640 didn't consider the compatible for old programs.
They did consider compatibility with old programs, which follow RFC959 and thus can rely on US-Ascii compatibility.
So if everything following RFC-2640, a RFC-2640 ftp server will only accept a RFC-2640 ftp client only, it will reject any non-RFC-2640 ftp client, because such client don't know UTF-8.
Simply not true: Clients following the old standard (RFC 959) still work. Also, if a client does not interpret the filenames, it can use the same names as reported by the server. Whether you see as client one character or some other doesn't matter if the underlying code (UTF-8) does not change. If server sends a character with the value 145 for example in a directory listing, it expects the client to request the file using the same 145 charactercode. How the client displays chars with that code is totally unrelated to the inner workings of FTP and purely a client problem.
For compatible, like other ftp server/client, they didn't follow RFC-2640 100%, because for a 100% RFC-2640 ftp server, only 100% RFC-2640 ftp client can communicate if the use non-english filename. most of them just make some modify for RFC-2640, they won't run in UTF-8 mode at beginning like RFC-2640, they choose to run in non-UTF-8 mode, so they still can communicate with the client without RFC-2640 support, and keep to support UTF-8 unitl client send 'OPTS UTF8 ON' command, then change to UTF-8 mode support like RFC-2640.
Can a client which talks iso8851-1 understand a server which uses Big5? Not at all. There has been no compatibility at all before. Now there is standardized compatiblity using UTF8.
Yes, transfer non-US-ASCII filename like BIG5 encoding will violate RFC 959, but, for us (Chinese, from Taiwan and Hongkong, who use BIG5 encoding), we already use BIG5 for a long time, and almost all ftp server and client allow us to transfer BIG5 filename directly.
A server should never ever violate specifications.

User avatar
boco
Contributor
Posts: 26913
Joined: 2006-05-01 03:28
Location: Germany

#38 Post by boco » 2006-06-23 01:09

Strangely, all the complaints and problems started right after UTF-8 was implemented into FZS (thats a good thing) and made mandatory (thats the bad thing).

Users don't ask to give up RFC compatibility, all we want is to have some sort of "compatibility mode" with non UTF-8 aware clients. The OPTS UTF8 OFF command was implemented (which is, BTW, AFAIK not mentioned in any RFC :) ). This command is great but has some disadvantages:

1. This command has no real use if you can't enter it :(
2. Some clients hang or stop before you can do anything

Thus, instead of issuing OPTS UTF8 OFF if we want NO Unicode, it would be better to use OPTS UTF8 ON if we actually want it.

Option1: FZS runs in UNICODE mode as it is now, and sends UTF8 in the FEAT response
Option2: FZS enables UNICODE only after OPTS UTF8 ON was sent, and does NOT send UTF8 in the FEAT response.

Personally, I would run it in Option2 mode, and I think I'm not alone.

I don't see any problems with it:

Option1 selected: FZS runs with full compliance to RFC

Option2 and no OPTS UTF8 ON sent: FZS runs like any version up to 0.9.14a did. I had never a problem with these versions...

Option2 and OPTS UTF8 ON sent: FZS behaves like non UTF-8 server with UTF8 extension enabled.

I really don't care for any misc. char, but I have problem with german umlauts (äöüß) which are very common in my file structure...

Long post, sorry for the bad English.

Summary line: A full RFC compliant server is of no use if you can use it only with 20% of the clients out there...

boco

User avatar
botg
Site Admin
Posts: 35508
Joined: 2004-02-23 20:49
First name: Tim
Last name: Kosse

#39 Post by botg » 2006-06-23 09:50

Strangely, all the complaints and problems started right after UTF-8 was implemented into FZS (thats a good thing) and made mandatory (thats the bad thing).
That's a good thing, it shows how many clients relied on unspecified behaviour (thats the bad thing).
boco wrote:Summary line: A full RFC compliant server is of no use if you can use it only with 20% of the clients out there...
Then 80% of the clients are broken. RFC 2640 is almost 7 years old, has been plenty of time for clients to implement it.

I'm aware of the fact that some users have problems with UTF-8 support, but that is the price to pay for relying on unspecified behaviour.
I won't ever add an option to disable UTF-8 by default.

That said, FZ client will continue to support broken servers which do not know about UTF-8 and use local charsets.

User avatar
boco
Contributor
Posts: 26913
Joined: 2006-05-01 03:28
Location: Germany

#40 Post by boco » 2006-06-23 11:44

*Sigh* OK. I give up. You won. :(

I guess I'll just have two FZS on my machine forever... 0.9.18 and 0.9.14a

boco

twu2
425 Can't open data connection
Posts: 45
Joined: 2005-02-26 16:54

#41 Post by twu2 » 2006-07-07 04:55

boco wrote:Will try your solution ASAP, maybe you could make an independent project?
I create a project in sourceforge, put the patch and build there.
http://sourceforge.net/projects/filezillapv

User avatar
boco
Contributor
Posts: 26913
Joined: 2006-05-01 03:28
Location: Germany

#42 Post by boco » 2006-07-07 15:19

Excellent!
twu2 wrote:If OPTION_UTF8_OFF is false, yes, FZ server will send UTF8 in FEAT as RFC-2640 said.
If OPTION_UTF8_OFF is true, don't sent UTF8 in FEAT.
This small change would make it perfect. FZS *MAY NOT* advertise UTF8 in FEAT response when UTF8 is disabled by default.

boco

lamamba
500 Command not understood
Posts: 2
Joined: 2005-04-20 20:32

#43 Post by lamamba » 2006-07-09 09:27

twu2 wrote:
boco wrote:Will try your solution ASAP, maybe you could make an independent project?
I create a project in sourceforge, put the patch and build there.
http://sourceforge.net/projects/filezillapv
thx for patch - i will be using it until my clients (total commander mainly) fully support utf8 or FZ server include this patch

one more thx

Freevo
500 Command not understood
Posts: 1
Joined: 2006-07-28 08:16

#44 Post by Freevo » 2006-07-28 08:35

botg wrote:If specifications are not obeyed, one ends up with something like Internet Explorer. Pages "optimized" for IE causing huge problems with all other brothers.
Your reasoning is false because of two reasons:
1. there is a possibility to make websites that follow the w3c standards AND work in IE very well. I'm talking about the strictest xhtml standard, which I use in all of my sites. But in this case, compliance depends on the server's maintainers, not the server itself.
2. Your case is like creating a webpage using CSS3 and a future XHTML 2 standard, and telling your visitors to throw away their browsers, because you followed the rules, and they use fossils as browsers. The only problem is that there is no browser to match these standards, and, unfortunately, compatibility is always determined by the clients, not the servers.
You'll be able to release a server, which follows your loved RFC standards after most, if not all the clients will fully comply with them. It's not your choice, it's the clients'.

User avatar
botg
Site Admin
Posts: 35508
Joined: 2004-02-23 20:49
First name: Tim
Last name: Kosse

#45 Post by botg » 2006-07-28 09:03

Ok, let's put it this way: If I wouldn't follow the new extension but the original specification, I would have to reply with "501 Syntax error in parameters or arguments." as non-english characters aren't supported at all.

Locked