I recently incorporated a pull request into riak-js that involved URI escaping for the HTTP client.
Shallow tests show that everything works fine, but once you start messing with links... you get bitten by this bug (#617). And I don't want to resort to the hack of double-escaping links. I think `mochiweb_util:unquote` should not be called there: https://github.com/basho/riak_kv/blob/master/src/riak_kv_wm_raw.erl#L1217-1219 (Imagine having a Protobuf (or native Erlang) client adding a link to ['bucket', 'r4nd0m-%40b0e-key'], to later stumble onto not_founds because ['bucket', 'r4nd...@b0e-key'] does not exist.) Base64url-encoding is not an option for us, because we heavily rely on meaningful keys. Thanks, Francisco 2010/8/13 francisco treacy <francisco.tre...@gmail.com>: > 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