Description

Permanent caching can be very "dangerous" in the way that you might introduce a problem that can never be resolved, because clients never revalidate the cache.

Sadly, by default, most browsers cache 301 redirects forever, unless explicit Cache-Control headers are set: https://makersaid.com/browser-behavior-301-redirects/

As there is always the possibility of sending an incorrect response and needing to correct it, it is always more safe to disable caching or limit it to a certain time frame.

At webfactory, we decided that we don't want any of our code to implicitly send 301 responses without cache-control headers. If there were use cases for caching 301 responses indefinetly long (which we couldn't think of), then we'd rather set this behaviour explicitly.

It turns out that Symfony once worked exactly the way we desire: Before #18220, Symfony would set cache-control to none unless configured explicitly. I see no strong arguments against this behaviour in neither the PR nor the corresponding issue.

So before we implement a custom solution I'd like to ask: would it be possible to revert the behaviour introduced in #18220, and have all Symfony users benefit from the safer behaviour?

Example 1

You have a long-running website called acme.com. The service at acme.com/product is available since decades, it has been promoted and printed on a lot of flyers both as text and QR code, people have bookmarked it and use it in their every-day work.

One day, a certain subset of pages at acme.com/other-product permanently moves its location to another company's website. Alice submits a patch to the Symfony code powering site that triggers 301 redirects under certain conditions. Sadly, under testing conditions, it wasn't appearent that this feature would accidentally add a 301 redirect to acme.com/product, too.

When you realise the problem after some hours, thousands of people have already been 301-redirected to the other site.

Because your Symfony app sent a 301 response without Cache-Control headers, those thousands of people will never again be able to use the acme.com/product URL to use your service – printed QR codes, social media and other online links and bookmarks will never work again for those people (unless they are tech-savvy and actively delete their browser cache).

You can't add a redirect back from the target URL, because the target URL is another very important URL which is owned by another business.

To not lose these users permanently, you have to switch to a new URL, and reprint all promotional material and re-promote it on social media.

Example 2

You decide to add a new service to your website, called "Product 2". You print a lot of promotional material using the URL acme.com/product2, and share it on social media. You tested the URL to work correctly on multiple devices.

But suddenly, you receive feedback from some customers, who can't access access acme.com/product2. After hours or days of debugging, Alice finds out that they get redirected to somewhere unrelated instead, but it's only on their devices and can't be repreduced anywhere else.

Turns out that 10 years ago, someone set up a 301 redirect from acme.com/product2. Those who used that redirect back in the day can't access the website you promoted for your new, important product.

Again, you have to redo the promotional campaign, with some image loss, as people might be confused by your back and forth and perceive you as unrealiable.