Add support for 'last-modified' and 'etag' cache headers

[liip]

Add support for 'last-modified' and 'etag' cache headers

[stof]

You should send a pull request instead of linking to the commit. It would make it easier to provide feedback and then to merge it

[lsmith77]

i am not sure if we really want to add this or at least not like this.
we can add a method into the data loader interface to get metadata on the resource.
the actual handling of setting cache headers should be done else where though imho. either inside a customized controller or via LiipCacheControlBundle.

see also #16
cc @MHeleniak

In my app I have handled this via another application dedicated for serving photos. Request to pic.example.com/filter_set/path/to/image.jpg is translated to www.example.com/media/cache/filter_set/path/to/image.jpg. In my case I have disabled caching in LiipImagineBundle as this is hadled by app behind pic.example.com.

Maybe it's not ideal (extra request) but it's much easier. @lsmith77 you mentioned in #12 that you done this the same way, right?

Btw. Don't send both ETag and Last-Modified headers. Only one of these is sufficent.

[advancingu]

@stof I couldn't immediately find out how to request a cherry-pick on Github so I posted the commit. My branch contains some other commits that wouldn't be of interest here.

@lsmith77 Yes, the design is not clean. The cache headers could be integrated into the cache resolver but they would also have to be set by the filter on its response to a non-cached request.

@MHeleniak Thanks for pointing out the headers. I actually realized that with my current code, only eTag should be used since last-modified wouldn't change if a filter configuration was updated.
The idea behind my implementation is that I don't want to handle storing filtered images on my server. I'll leave this to proxies.

[lsmith77]

@advancingu there is nothing special to do on github. simply create a new branch locally from the current master of this repo, cherry-pick your commit and push and open a PR.

"The cache headers could be integrated into the cache resolver but they would also have to be set by the filter on its response to a non-cached request."

This should be entirely possible inside a custom cache resolver.