Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Memcache-Client Accepts Non-Compliant Keys #1

Open
animecyc opened this issue Feb 10, 2018 · 0 comments
Open

Memcache-Client Accepts Non-Compliant Keys #1

animecyc opened this issue Feb 10, 2018 · 0 comments

Comments

@animecyc
Copy link

The memcache-client will accept keys that would cause the send to fail, you wont see this with the value as the data is packed. According to the ASCII protocol keys should be encoded, see: https://github.com/memcached/memcached/blob/ca66b826f25e1db83d191780e0bcac4a070c6911/doc/protocol.txt#L595-L598

The value of keys (and potentially other things) are "URI encoded". Since most
keys used conform to standard ASCII, this should have no effect. For keys with
less standard or binary characters, "%NN"'s are inserted to represent the
byte, ie: "n%2Cfoo" for "n,foo".

One thing to note is that when a bad key is sent across the wire it puts the client in a bad state. The dequeued command fails, i'm not sure why. Subsequent commands will also fail.

I'm not sure key encoding should be an application concern, however, it seems like an oversight given you're able to easily break the existing delegate methods like set and get and put the client in a non-working state. Let me know if you need more info.


Reproduction

// Won't Work
someClient.set("my bad key", "my goo value")

// Work
someClient.set(encodeURIComponent(badKeyVal), value, (err, res) => console.log(res));
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant