Liipimaginebundle: Images that have not yet been generated will cause a redirect loop in <img> html

[leroy0211]

| Q | A
| --- | ---
| Bug Report? | yes
| Feature Request? | no
| BC Break Report? | no
| RFC? | yes
| Imagine Bundle Version | ^1.8

When a filtered image is generate from inside an html <img /> tag it will cause a redirect loop. Because the browser caches the 301 response. It's not the code that generated the redirect loop.

The RedirectResponse removes the cache-control header on 301 responses, because that's a permanent redirect. 302 redirects are temporary and will not remove the cache-control header.

So in the ImagineController should use a 302 redirect instead of a 301 redirect.

[makasim]

I don't think changing 301 to 302 is a good solution. The 301 will instruct the browser not to go to the old URL (the controller) and always use the cached static image.

The problem has to be investigated and another solution found.

[trsteel88]

It shouldn't cause a redirect loop? The 301 is going from _/media/cache/resolve/path.jpg_ to _/media/cache/path.jpg_

[leroy0211]

I think I know where my issue comes from.
I changed the routing to /media/image/{filter}/{path} and that controller redirects me to the same URL.
Because nginx is configured to use the static file first that should work without touching any PHP.

I wanted to achieve 1 single URL for each image, because it's wrong in SEO perspective to have multiple url's for a single image, although the "primary" image causes a redirect.

[trsteel88]

There shouldn't be an SEO issue as it is a 301 redirect. Google should follow the redirect through and only index the 200 response code.

The resolve path is only displayed while there is no cache. As soon as the cache is generated the html will return absolute path to the image.

[leroy0211]

I think I'm reverting the change in the route url, and resolve them in PHP. So I would never get the /resolve url. It's because I'm using LiipImagine as API to upload images, and cannot work with multiple url's in my app. I thought that getBrowserPath always returned the /resolve url even if it already was generated.

But thanks anyway for clearing up my issue!

[adm-bome]

As we are at work and we are sitting next to each other. We encountered this issue. As we changed the route, to something we found more suitable, we got this problem. With above clarification and some debugging. We decided to (pre)resolve the images. @leroy0211

[makasim]

We decided to (pre)resolve the images. @leroy0211

FYI: http://symfony.com/doc/current/bundles/LiipImagineBundle/resolve-cache-images-in-background.html