Breaking change with 301 redirects and Symfony 3.2

[lstrojny]

Q	A
Bug Report?	yes
Feature Request?	no
BC Break Report?	yes
RFC?	no
Imagine Bundle Version	1.7

Symfony 3.2 changes the default behavior for 301 redirects to no longer set cache headers (symfony/http-foundation@6802c88). Chrome for example caches 301 redirects when no specific cache header is specified leading to infinite loops.

Changing the redirect from 301 to 302, which is arguably also semantically more correct, fixes it.

[makasim]

I dont think it is correct. The cache image is generated and the new url must be used at all times. that's what 301 is for isn't it?

[makasim]

the resolve controller should never ever be called once the cached image is created.

[robfrawley]

The use of a 301 has always been a widely discussed topic; is there a reason we haven't simply allowed people to configure their preferred redirect type (a 301 or 302)? There are use cases for calling the resolve controller every time.

That said, back to the original issue, I'm not sure a 302 is how we want to handle the default implementation; as stated, we don't want the resolve controller to be called once the cache is created. Do we need to assign additional headers now due to the Symfony change? I don't have time to check out the referenced PR ATM; I'll further investigate it when I have some time later.

[lstrojny]

@robfrawley one alternative would be to set no cache headers for the 301 redirect. The issue is that the redirect goes to the same URL and therefore Chrome users will have 301s cached and run into infinite redirect loops.

[makasim]

Do I miss something? The urls are not the same. The controller's url has /resolve/ in its path.

[lstrojny]

@makasim depends on the configuration. We use the same URLs, which escalates the whole thing. We configure it so that /image/foo.jpg will use nginx to look up the format in a folder and if it’s not there fall back to the controller. We keep the URLs the same so that once the proper image is generated it can nicely live in the CDN under the proper URL and we can shortcut the whole controller dance once it is generated.

[makasim]

@lstrojny I see. it has to be configurable than.

[lstrojny]

@makasim I wonder if configuring the status code is enough or if a ResponseFactory would be a good idea so that people can do crazy stuff if they need to.

[makasim]

I've just realized that this is already possible. One can register a kernel response listener and do what ever they want there from changing the status only to replacing the whole response object with the new one.

If so, we need a tutorial that helps people.

[robfrawley]

Makes sense; we should add an example of doing so to the RST documentation. In the meantime, why not introduce a configuration option for the redirect response type: many others have asked about using one redirect over the other for ages, and adding this option would solve a simple and common use-case. The custom event listener/subscriber shouldn't be required to change the redirect type, IMHO, but it is a very powerful alternative for those that require even most advanced customization.

[lstrojny]

Made it a simple setting for now. If a user wants more one can still overload the controller action

[robfrawley]

Resolved via #970.