[9.x] Do not let SetCacheHeaders override the eTag.

[lucasmichot]

In some cases, I want to have the possibility to set my own response eTag, based on other arguments than just the the response content.

If so, I do no want it to be overridden when using SetCacheHeaders middleware.

[taylorotwell]

Can you give an example of this? I'm not following.

[inxilpro]

I can see using this, although I would do the same for Last-Modified. Right now we don't use the SetCacheHeaders middleware because we need more control over those headers, and the middleware overrides existing headers if they're set.

For example, if I had something like this, where I wanted to set the Last-Modified and ETag headers based on a model's data:

Route::get('/pages/{page}', function(Page $page) {
  return Response::create($page->toHtml())
    ->setLastModified($page->updated_at)
    ->setEtag(md5($page->body), true);
});

The SetCacheHeaders middleware would override my custom values. So my options are to manually pick which routes to apply the middleware to, or just handle cache control headers some other way.

Updating SetCacheHeaders to only generate headers if they're missing would solve that problem. You could just add it to a middleware group or globally, and know that if you don't manually apply the headers, they'll be generated for you.

[lucasmichot]

Sorry for the late reply, @inxilpro summed it up way better than I could.

---

This PR initially initially ensures that the eTag is not overridden if already set, but the same could also apply to the Last-Modified