2010/8/12 Bryan Fink <br...@basho.com>: > Hi, Francisco. I've run into this myself in developing a recent > application. I've been loathe to change the Riak behavior, for > worries of breaking existing client expectations. The original > escaping was put in to deal with objects that had been created by the > native Erlang client, and therefore might have non-url-safe keys. I'm > fairly certain I now agree that Riak should never mess with escaping, > though (and that non-url-safe keys should be treated as errors for the > HTTP interface).
Yes, we agree Riak should never mess with escaping *and* non-url-safe keys should be treated as errors for the HTTP interface (or for all, what if you save a document via Erlang or the protobuf interface and then you want to retrieve it with HTTP GET?). I think not only it's important to fix https://issues.basho.com/show_bug.cgi?id=617 , but also to clearly state how client lib implementors should deal with this (basically, that they should take care of all escaping in a uniform manner). > In the meantime, a good workaround is to base64-encode keys used over > HTTP. As long as you use alternate characters for + and / (like - and > _, called "base64url" on http://en.wikipedia.org/wiki/Base64), you end > up with urlencode(base64encode(Key)) == urldecode(base64encode(Key)) > == base64encode(Key). If I understand correctly this would involve changing my keys and atm it's not really feasible in our app. As a workaround until this is fixed, I patched Ripple so that it doesn't escape: http://github.com/frank06/ripple/commit/baa326f0f6041f9ab2401e0606cd35533e878cf0 (works ok so far). Thanks, Francisco _______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
