If3e20c6 and the following patches introduced a breaking change and
cause a regression in Wikibase because we are using the version number
constant as part of a cache key prefix. Currently the Wikibase version
is set to "0.5 alpha".
Space characters were allowed before and encoded as "%20". This does
not happen any more.
Change-Id: Ia2fd4ed6738a10e02050bced947ef5d4e8b98980
* Follow-up to 0c9fb12265
* Make sure colons actually get escaped
* Added more unit tests
* Also fixed the test actual/expected order
Change-Id: Ie04ea6059ee1eb6d1da8f30fefdec52fa49d38fb
For the sake of safety and correctness, the following BagOStuff::makeKey()
invocations should return distinct keys:
$cache->makeKey( 'ab:', 'cd' );
$cache->makeKey( 'ab', ':cd' );
That is not currently the case, because while we use ':' as a key path
separator, we don't escape ':' in the input supplied to makeKey(). So, make
BagOStuff::makeKeyInternal() URL-encode colons.
To prevent this from messing up the max. key length calculations, reproduce
this logic in MemcachedBagOStuff::makeKeyInternal(), in lieu of having the
method call its parent.
Change-Id: I83ea7e7336a1c9e64aa42284c2517089a736efe5
Currently we have to undo any transformations we apply to keys in getMulti() by
iterating over the response array keys reversing any changes. This is hairy and
complicated. So --
* Replace calls to MemcachedBagOStuff::encodeKey() with calls to a new method,
MemcachedBagOStuff::validateKeyEncoding(). The new method only validates that
the key is compatible with memcached. If it is not, it throws an exception.
If it is, it returns the key unmodified.
* Remove MemcachedBagOStuff::{encode,decode}Key(), since they no longer serve a
purpose, and have no callers.
Change-Id: If3e20c6a1a1b42fc1f2823aa660328e37c26eccb
The motivation for this patch came from seeing the following error in the
memcached log:
memcached ERROR: Memcached error for key "flowdb:flow_ref:wiki:by-source:\
v3:0:tawikinews:பூமிக்கு_அச்சுறுத்தலான_சிறுகோள்களைக்_கண்டுபிடிக்கும்_முயற்சியில்_தனியார்_நிறுவன0jம்:4.7" \
on server ":": A BAD KEY WAS PROVIDED/CHARACTERS OUT OF RANGE
I submitted a fix to Flow in I26e531f6, but I noticed that AbuseFilter had a
similar issue (fixed by Aaron in I27b51a4b), so I started thinking about how
to solve this more generally:
* The regular expression we current use to sanitize keys does not cover
characters outside the ASCII range, but such characters can be illegal
if one of their constituent bytes (when taken by itself) is an ASCII
control character. So change the regular expression to cover any and all
characters that fall outside the range \x22-\x7e (and '#' -- see below).
* Enforce a key length limit of 255 bytes, which is the maximum length
permitted by the memcached protocol. The Tamil segment in the key above is 84
characters, but 233 bytes in UTF-8, which become 684 characters when
URL-encoded. To fix this, try to shrink any segment that would push the total
key length over the limit by md5()ing it. If the end result is *still* over
the limit (this would happen if, for example, $args consists of many short
strings), then concatenate all args together and MD5 them.
* MD5'd arguments are prefixed with '#'. Any "organic" '#'s in the key segments
are URL-encoded.
Change-Id: Ia46987d3b0a09bb6b1952abd936d4c72ea7c56a0
