On Sunday 31 January 2016 07:27 AM, Andre LaBranche wrote:
On Jan 30, 2016, at 1:18 PM, Andre LaBranche <dre@apple.com <mailto:dre@apple.com>> wrote:
This is not expected. Does memcached need to be configured for Unicode, maybe?
It looks like we expect to be in ascii mode, as far as memcached is concerned:
You can debug the memcache side of this by configuring calendarserver to not launch memcached; instead you'll do so manually, in the foreground.
Edit caldavd.plist, and insert the following Pools configuration under the Memcached dict:
<key>Pools</key> <dict> <key>Default</key> <dict> <key>MemcacheSocket</key> <string></string> <key>ServerEnabled</key> <false/> <key>BindAddress</key> <string>127.0.0.1</string> <key>Port</key> <integer>11211</integer> </dict> </dict>
Manually start memcached in verbose mode on 127.0.0.1: memcached -l 127.0.0.1 -vv
Start calendar server, load a principal page: https://whatever:8443/principals/users/you
As you log in, you should see stuff in the memcached window:
<22 new auto-negotiating client connection 22: Client using the *ascii protocol* <22 get DIGESTCREDENTIALS:...
22 END
Also try the following test script which sets and gets unicode strings. bytes. whatever they are :) In SVN mode, I run ./bin/python mctest.py from the SVN dir to make sure the interpreter has access to six and memcache. If you don't use SVN mode, and don't have these modules installed system-wide, edit PYTHONPATH to help your interpreter find these modules.
#!/usr/bin/python # -*- coding: latin-1 -*- from __future__ import print_function
import six from memcache import Client, SERVER_MAX_KEY_LENGTH, SERVER_MAX_VALUE_LENGTH
servers = ["127.0.0.1:11211"] mc = Client(servers, debug=1)
def setget(key, val): mc.set(key, val) newval = mc.get(key) print("key:", key) print("set:".rjust(8), val) print ("got:".rjust(8), newval, "\n")
setget("ascii", "xyzzy")
setget("unicode_1", six.u('\U0001f648')) setget("unicode_2", six.u('\u25c9')) setget("unicode_3", six.u('\u4f1a')) setget("unicode_4", six.u('dr\\xe9'))
mc.disconnect_all()
Output looks like:
key: ascii set: xyzzy got: xyzzy
key: unicode_1 set: 🙈 got: 🙈
key: unicode_2 set: â—‰ got: â—‰
key: unicode_3 set: 会 got: 会
key: unicode_4 set: dré got: dré
... and the memcached log confirms we're still in ascii mode:
<25 new auto-negotiating client connection 25: Client using the ascii protocol <25 set ascii 0 0 5
25 STORED <25 get ascii 25 sending key ascii 25 END <25 set unicode_1 0 0 4 25 STORED <25 get unicode_1 25 sending key unicode_1 25 END
-dre
Tried the experiment. Here is the output: root@wheezy:/tmp# python test.py key: ascii set: xyzzy got: xyzzy key: unicode_1 set: 🙈 got: 🙈 key: unicode_2 set: ◉ got: ◉ key: unicode_3 set: 会 got: 会 key: unicode_4 set: dré got: dré and here is the memcached log: <37 new auto-negotiating client connection 37: Client using the ascii protocol <37 set ascii 0 0 5
37 STORED <37 get ascii 37 sending key ascii 37 END <37 set unicode_1 0 0 4 37 STORED <37 get unicode_1 37 sending key unicode_1 37 END <37 set unicode_2 0 0 3 37 STORED <37 get unicode_2 37 sending key unicode_2 37 END <37 set unicode_3 0 0 3 37 STORED <37 get unicode_3 37 sending key unicode_3 37 END <37 set unicode_4 0 0 4 37 STORED <37 get unicode_4 37 sending key unicode_4 37 END <37 connection closed.
What next :)? I believe I could however safely go ahead and upload the new calendarserver version as this bug does not seem to breaking any functionality. Thanks, Rahul.