php-http / cache-plugin Goto Github PK

PHP version: 7.3

Description

Getting these warnings reported in Sentry on some requests. The chance of this error happening is roughly 1%.

https://github.com/php-http/cache-plugin/blob/master/src/CachePlugin.php#L150

How to reproduce
Not entirely sure to be honest. Using the PSR16 adapter of https://www.phpfastcache.com/ with the Redis driver, and the Symfony cache adapter to convert PSR16 to PSR6. It only happens on a small subset of requests. I'm wondering if this is a race condition, when the cache item expires in between cache lookups. First call sees if item is in cache, by the time the second call tries to get the data, the item has expired.

Possible Solution

Check $data for null before processing further.

See php-http/plugins#57, @dbu wrote:

the CachePlugin should handle Last-Modified and Etag headers and send If-None-Match resp. If-Modified-Since headers along if the data is still in the cache. this would allow the server to respond with a 304 Not Modified and we could update the cached response and then return that.

Sometimes the max age can be large, resulting in the total cache size becoming absolutely massive because there's loads of data with long TTLs. It would be convenient to have the TTL be the minimum out of the default ttl and the max age, instead of the sum, perhaps?

I think the way to get around this for now is going to be wrap up the psr cache in a class that limits the TTL.

See php-http/plugins#56

Actual Behavior

The cache key is currently generated based on the following details:

• hash algo
• request method
• URI
• request body

Expected Behavior

One should be able to customize this behaviour.

Example: Separate cache entry per authorization header.

Possible Solutions

Introduce a CacheKeyGenerator interface which would receive the request as a parameter.
It should be an optional parameter of the plugin, falling back to the current implementation.

See php-http/plugins#59

I know this library calls out it's specifically a psr 6 caching plugin -- so I wasn't sure if I should put this here or on the main HTTP libraries issues list. Since psr 16 the simple cache interface has been accepted by the FIG I was wondering if it was possible to have this plugin support both? The main rationale being since there are two standards its possible for projects to be using a caching library that uses psr 16 but not psr 6.

It is for respect_cache_headers.

From @GrahamCampbell KnpLabs/php-github-api#557 (comment)

We have the following code in CachePlugin.php:

    public static function clientCache(CacheItemPoolInterface $pool, StreamFactoryInterface $streamFactory, array $config = [])
    {
        // Allow caching of private requests
        if (\array_key_exists('respect_response_cache_directives', $config)) {
            $config['respect_response_cache_directives'][] = 'no-cache';
            $config['respect_response_cache_directives'][] = 'max-age';
            $config['respect_response_cache_directives'] = array_unique($config['respect_response_cache_directives']);
        } else {
            $config['respect_response_cache_directives'] = ['no-cache', 'max-age'];
        }

        return new self($pool, $streamFactory, $config);
    }

If I pass a config with 'respect_response_cache_directives' => [], it is ignored and replaced with ['no-cache', 'max-age'].
I wanted it to always cache any page regardless of the server directives. It's impossible to do that right now. I'm not sure what's the intention of the code above.

Hey!

It seems since the last changes, I'm not able to don't consider headers at all.

Here, my set up:

$this->client = new PluginClient(new Client(), [
    new ErrorPlugin(),
    new CachePlugin(
        new FilesystemAdapter('', 0, __DIR__.'/cache'),
        new GuzzleStreamFactory(),
        ['respect_cache_headers' => false]
    ),
]);

After debuggint it, I would update https://github.com/php-http/cache-plugin/blob/master/src/CachePlugin.php#L78 by:

if (!$this->config['respect_cache_headers'] || (isset($data['expiresAt']) && time() < $data['expiresAt'])) {

WDYT?

PHP version: 8.0.1

Description
Installation fails with PHP 8.0.1 & psr/cache 2.0.0:

Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - php-http/cache-plugin 1.7.0 requires php ^7.1 -> your php version (8.0.1) does not satisfy that requirement.
    - php-http/cache-plugin 1.7.1 requires psr/cache ^1.0 -> found psr/cache[1.0.0, 1.0.1] but the package is fixed to 2.0.0 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
    - Root composer.json requires php-http/cache-plugin ^1.7 -> satisfiable by php-http/cache-plugin[1.7.0, 1.7.1].

Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.

Installation failed, reverting ./composer.json and ./composer.lock to their original content.

Possible Solution
Submitted a PR for this.

When creating cache pool (e.g. in Symfony), user must choose default lifetime. When using php-http cache-plugin, user must again configure default_ttl option.

These two options do the same thing. There should be a way to configure cache plugin to let expire cache items organically by cache pool.

This is problematic, because lot of times I create separate cache pools for each http client and I have to duplicate this configuration and making sure changes in them are propagated to all places.

Furthermore, cache plugin implements expiration functionality by itself unnecessarily. There is no need to store expiresAt data, that's what is $cacheItem->expiresAfter() call for.

What is left to be done before 1.1?

See php-http/plugins#58

Actual Behavior

The cache uses any item matching the key and may error if the content does not match what it expects.

Expected Behavior / Possible Solution

The cache should treat an item that was potentially created by another service with a colliding key as a reason to skip caching the resource with this key.

Hey!

While working on egeloen/ivory-google-map#221 which will allow to slow down http requests according to Google rates limits, I'm facing a little issue about the cache plugin.

Basically, the plugin I wrote use usleep when needed and in some applications, end users will also use the cache plugin in order to reduce its http requests (allowing to reduce daily quota as well as 💰 if it pays for qps/shared quota increase).

In tests, I rely on both plugins and my plugin is trigerring usleep call whereas it should not since the response comes from the cache and technically, the Google API has not been reached.

I have read the cache plugin code and I can't see anything allowing me to easily detect such case. For now, the only solution I see it to replicate how the cache plugin generates its cache key and check in the cache entry is available in the pool.

Do you see how I can deal with such feature?

It would be really cool to have a way to tell the cache plugin to only cache using etags, and ignore anything else, even if valid cache headers with future expiry.

The cache PRS's all write a string to the cache. This means that response bodies have to be placed in memory and serialized to do so. This can become a problem when you're caching large responses.

The Http Response classes already work with streams. It would be nice if this plugin just pipes the stream to a cache. When fetching you can then open the stream and use that as response body.

once #30 is done, we should implement different cache key strategies for the client and server mode of the plugin. as client, the key should take into account authorization headers (Authenticate, Cookies). in server mode, requests with cookies and or authentication should not be cached at all.

PHP version: x.y.z (hint: php --version)

all

Description

Package php-http/message-factory is abandoned, you should avoid using it. Use psr/http-factory instead.

How to reproduce

composer install with any pacakge that uses it.

Possible Solution

use psr/http-factory instead

since #26, the no-cache directive is correctly handled. the response is not cached. but no-cache is meant to force re-validation - the response might still be stored but needs to be revalidated each time.

AFAIK you can actually cache the result if response has no-cache directive. It just means you must always revalidate before actually using the cached result. If origin server returns 304 Not Modified you can use the cached result.

https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1

Hi,
it seems there is no tag for version 1.6.0, even though there is record for it in readme.

IMHO the tag 1.6.0 should point to 5ae8a80 .

In src/CachePlugin.php, PSR-7 responses are serialized as is, except the response body, which is serialized separately.

Recently the PHP engine started to throw deprecations when a resource is found in a serialized data structure.
And this happens to PSR-7 responses: whatever the implementation, their body is a represented as a stream resource internally.
Also, from an abstraction PoV, nothing says in PSR-7 that responses are serializable, which means interop should consider them as non-serializable.

The plugin should be improved to not store PSR-7 objects directly, but intermediate representations that fit a generic cache backend.

Actual Behavior

When you are initialising the CachePlugin in server mode (using CachePlugin::serverCache, for example), the s-maxage directive of the Cache-Control header is never taken into account which means that cacheable responses are always cached with the default TTL.

Expected Behavior

The s-maxage directive is used as the TTL for cached responses.

Steps to Reproduce

Send requests to an endpoint where the shared max age directive's value of the Cache-Control header is different than the default TTL. Cache entries will expire after the default TTL.