Cache keys with reserved characters are no longer accepted

[greg0ire]

BC Break Report

Q	A
BC Break	yes
Version	3.2.0

Summary

Previous behaviour

It was possible to use a cache key with a reserved character, such as :

Current behavior

An exception is thrown from https://github.com/doctrine/cache/blob/331b4d5dbaeab3827976273e9356b3b453c300ce/lib/Doctrine/Common/Cache/Psr6/CacheAdapter.php#L265

How to reproduce

1. Configure a doctrine/cache instance as a result cache (for instance, I've been using https://github.com/symfony/symfony/blob/0ac7aa230fe0177214415ee20fec113a44a261f1/src/Symfony/Component/Cache/DoctrineProvider.php#L60).
2. Set a key with a : in it.

Possible solution

Use rawurlencode in doctrine/cache instead of throwing, release a new version, require that version.

In my case, the issue was easy to fix as we had only one occurrence of a key with a colon inside in our project, so if for some reason this is too hard to fix, we might instead just document the BC Break

[morozov]

While technically it is a BC break, I'd look more into the reasoning behind PSR-6 allowing its implementors not to support the special characters. It would be close to trivial to encode them but there may be reasons not to do that.

Personally, I never understood this limitation but now it might be a good time to understand it better.

[greg0ire]

From https://www.php-fig.org/psr/psr-6 :

The following characters are reserved for future extensions and MUST NOT be supported by implementing libraries: {}()/\@:

Apparently, special functionality might kick in if you use those (once such extensions are added to the standard).

There isn't much more detail over here: php-fig/fig-standards#786 or in the google group.

[morozov]

Encoding logic into values using reserved characters looks like… SQL? With all the possibilities for logic injections and thus the need for sanitization and then an API like prepared statements to avoid those? It looks like we've already been there.

Personally, I would rather document it as a minor BC break rather than try fixing something that won't work with the PSR-6 implementations anyways.

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.