Probably useless because it is already handled for Doctrine and not reliable enough for non-Doctrine data providers.

Probably useless because it is already handled for Doctrine and not reliable enough for non-Doctrine data providers.

You should use php-http/httplug for better interop.

Maybe when it will be a PSR. But for now it has nos advantage over using Guzzle 6 for this use case: it is harder to setup (requires to install an extra Symfony bundle), adds complexity and a (small) performance overhead.
Guzzle 6 is already an abstraction layer, with builtin curl and streams implementations. We only depend of the ClientInterface, it's easy to bridge other implementations (but I think it is not worth it).

As we support PHP 7 only, we don't target older libraries such as Guzzle 5.

I didn't catch the last point. 👍

@dunglas IMHO, you should consider using buzz. And It's not a joke:

• Guzzle have so many version, and these versions are not compatible each others. So people that are using a version that is incompatible with guzzle 6 will be blocked.
• Buzz is very simple and works well

AFAIK it doesn't support async requests... and it has not been updated since 2015.

When guzzle guys will release the 7.0 version, you will be stuck with the 6.0 version. Http clients are a widely common dependency and so conflicts may appears. But ATM you could go with guzzle 6. Using httplug could be added later.

I have a very strong (I think) argument for using HTTPlug: you do not get into hell like FOSHttpCache did (and still is) with their hard coupling to a specific Guzzle version.

A PUT may change the value of an attribute used to order a responses. You should invalidate collection too

Good catch, I add this.

What's about related_dummies who was previously linked to this entity? They should be invalidated too

They will be, because they are marked with /relation_embedders/1.

indeed

I don't understand in you code how you make the link between relation_embedders and third_levels? Who flaged it?

It's because of this line: https://github.com/api-platform/core/pull/952/files#diff-0362bfae91549bcd08af0d06bd806b37R14

md5 obfuscate tests... :(
I wonder if a dedicated context could be more readable: the cache-tag header should be equals to "/relation_embedders, ...."

True, I'm working on a fix to remove the hash and use plain IRIs. I'll update the PR when it's ready.

Don't forget user with several varnish servers

Circular reference is only because of IriConverter no? Can't you inject the ResourceManager properly though?

A small comment to explain what goes below would be great for future readers!

indeed

I suggest to move the purge as close as possible to the transaction (doctrine postFlush IMO)

I understand your point of view to return a response to the user as soon as possible, but this introduce cross concurrency bugs.

Example:

• list all blogs (cache mis)
• post a blog
• list all blog (cache hit when called before the kernel terminate even)

I already have this issue in the my CI (agreed, this is a particular case with a lot of stress tests). but the probability of cross concurrency is higher when:

• you have several varnishes to purge
• you have other kernel.terminate events with an higher priority (sending an email for instance)

^ That does not actually address the race condition, but only trying to avoid it.

indeed, it fixes one case.

BTW (not related to the RC): A small improvment for the user would be to start async request on the postFlush event, and wait on the kernelFinish event.

I suggest to add a LastModified header too initialized to the default value now().
As a result, Varnish will handled it for free (by default), and returns 304 code stuff.

This small change should not interfer in your App and how you invalid cache. But will save bandwidth between the user and varnish.

Varnish already returns 304 response properly. We should not send bogus Last-Modified headers.

I thought this listener was used only with "tag" thing. I apologize, agreed, this header don't make sens here.

But I think, you missed my point, the idea, when using tagged response, is to add a validation header (could be etag or last-modified, don't care). To save bandwidth between users and varnish when cache is hit.

IMO we should provide a good default config for this (in the standard edition) but let the user configure it as he wants.

@jderusse:

the idea, when using tagged response, is to add a validation header (could be etag or last-modified, don't care). To save bandwidth between users and varnish when cache is hit.

That's incorrect. Varnish already sends 304 response with proper ETag in that case. There is no need for the backend to send an ETag or Last-Modified header unless the backend intends to return 304 on vcl_backend_fetch.

Let explain with a schema (my last try)...
Here is the actual implementation

My objective is to transform the last response in step 6 into a 304.

• To do it, varnish need a if-none-match header in step 5
• To do it, client need a etag header in step 4
• To do it, varnish needs nothing, it just forward the response from the app from step 3
• To do it, app must send this header <= this is my point

And Here is the target sequence

Your last comment suggest that varnish add this header by it self, with something like that

Is it what you mean? Because I doubt varnish add such header by itself (unless you implement this behavior in a VCL which is fine to me too)

Because I doubt varnish add such header by itself

Varnish does it by default. Try it. At least it has been doing so since 4.0 😄

I bootstraped an empty api-plateform from this PR api-platform/api-platform#238

curl test2_varnish_1.docker/foos -i
HTTP/1.1 200 OK
Server: nginx/1.11.10
Content-Type: application/ld+json; charset=utf-8
X-Powered-By: PHP/7.1.3
Vary: Content-Type
X-Content-Type-Options: nosniff
X-Frame-Options: deny
Cache-Control: public, s-maxage=3600
Link: <http://test2_varnish_1.docker/docs.jsonld>; rel="http://www.w3.org/ns/hydra/core#apiDocumentation"
Cache-Tags: /foos
Date: Wed, 22 Mar 2017 07:23:50 GMT
X-Varnish: 26 32789
Age: 3
Via: 1.1 varnish-v4
Accept-Ranges: bytes
Content-Length: 111
Connection: keep-alive

{"@context":"\/contexts\/Foo","@id":"\/foos","@type":"hydra:Collection","hydra:member":[],"hydra:totalItems":0}

varnish don't add validation header 😕

@jderusse You're right. I overlooked that FOSHttpCacheBundle was the one adding it. My apologies...

I think we should use the same approach. Just use the MD5 hash of the Response content as ETag. MD5 is cheap, so no reason to use a meaningless Last-Modified. 😄

Doing a md5 of the response is not ok (the response contains the date). We may do a md5 of the response's body.

When enable_tags is true and maxAge > 0. We should warn the developer that the browser will cache responses and remove the benefits of cache invalidation.

It can be intended (I often do that). It allows to always serve fresh data for the first request but reduce the server load/bandwidth usage thanks to expiration. It's often not a problem when the TTL is low. I would let the user do what he wants without warning.

This tight couple the purge system with http requests context which is used like a databag.

Yes I'll try to find a better solution but I'm not sure there is one. Anyway its called purge HTTP cache, it's not a big deal to couple it with the HTTP request.

Is there any reason for this property in the context?

Good catch, it has nothing to do here!

through?

no parenthesis here, but the line above yes?

The parenthesis on the previous line are mandatory because of operator priorities.

Shouldn't we avoid changing those tests? It feels like the tests (this one and the others) won't pass without 2 more arguments (eg, null, ['resources' => []]). Is it the case / Isn't this breaking things somehow?

It passes without the arguments and without change, but I've modified it to test the new behavior.

Okay as long as there is a test that doesn't adds up those arguments.