On Sunday 31 January 2016 07:27 AM, Andre LaBranche wrote:
On Jan 30, 2016, at 1:18 PM, Andre LaBranche <d...@apple.com
<mailto:d...@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.
_______________________________________________
calendarserver-dev mailing list
calendarserver-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/calendarserver-dev
