-
Notifications
You must be signed in to change notification settings - Fork 323
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
Undocumented 3.2.0 change: non-ascii keys no longer supported. #546
Comments
I don't really understand why you think it is a major change. libmemcached always did an isgraph() check, so these keys were failing at the libmemcached level. It was inconsistent for the check at the extension level not to use the same check. And it caused all sorts of confusion to sometimes have bad keys error at the extension level and other times at the libmemcached level. None of these keys were getting through before, it is solely about where it was caught and it is much cleaner to always catch it at the extension level. if/when libmemcached changes their check, we will follow suit at the extension level. |
Hmmm, is the resulting error code just different? We were not seeing a "negative" response code with some of our keys before upgrading from 3.1.5 -> 3.2.0, and now we get bad key errors. I'll dig up exactly what characters are giving us behavioral changes. |
Yes, libmemcached has always done an |
Run in a https://psysh.org/ REPL. I'll try to get you reproducing example repository in the next few days: Memcached 3.1.5 extension:
Memcached 3.2.0 extension:
Talking to the same target memcached instance (in this case, technically google memorystore for memcached, but I don't know how relevant that is) |
which libmemcached version? |
Good question, you're going to hate me:
which is presumably stock 1.0.18. I'm gonna try to get you a reproduction with 3.2.0 running normal libmemcached 1.0.18 |
https://github.com/SpencerMalone/memcached-315-320-key-replication is the replication with standardized libs:
Running the following test PHP script:
|
So this is a weird edge-case that happens to work. If that is really your production code it means you are not doing any key verification client-side which is a bit risky.
I think you will find that this key gets caught by libmemcached's key check. But maybe we need to skip that check in the PHP extension when |
I definitely agree with that :) (both on "this showed us we need to be more stringent about sanitization of user input into keys" and "enabling that option") I actually didn't know that flag existed until I was digging in the issues and PRs for this repo today. Not sure how to get https://www.php.net/manual/en/memcached.constants.php updated, but I've noticed there's some other missing options and constants on there over the years. I'm gonna throw one more wrench into this: The behavior of forcing verification of (in particular) no spaces in keys has been part of the 3.x behavior for years now, I know #519 says this isn't the job of the extension, but defaulting to disabling that may open up a bunch of people to memcached injections through key manipulation. I personally would love to either see OPT_VERIFY_KEY default to on, or keeping "no spaces in keys" validation in place (even though it is superfluous with "only graphical characters" IIRC) |
I've updated the PR to keep the check for spaces in keys even if key verification is not enabled |
- Add #515 option to locally enforce payload size limit - Add #539 zstd support - Add #540 compression_level option - Mark password as a sensitive param for PHP 8.2 - Fix Windows PHP 8 compatibility - Fix #518 Windows msgpack support - Fix #522 signed integer overflow - Fix #523 incorrect PHP reflection type for Memcached::cas $cas_token - Fix #546 don't check key automatically, unless client-side verify_key is enabled
In #479 we moved from
iscntrl
->!isgraph
. The problem there is non-ascii characters are "not graphical", but they are valid keys according to the memcached server.I understand the libmemcached client does a
!isgraph
, and thus it may be worth adopting this (even though protocol does technically support non-ascii keys), but at a minimum this should probably be a major release as unexpected loss of keys is a really scary unexpected change.The text was updated successfully, but these errors were encountered: