[6.x] Fix for issue Content Type not specified

[adam1010]

This fixes issue #31518 where Laravel isn't setting a Content-Type and so Symfony is just setting it to whatever the request is asking for. This is poisoning our cache, randomly serving up our website HTML pages as "text/xml" (which causes Chrome rendering errors).

This is a regression caused by a recent update to the underlying Symfony framework, but affects Laravel because we chose not to specify the default Content-Type.

[driesvints]

You can't know that the response is text/html. It could be a binary file, text/plain, literally anything.

[taylorotwell]

@driesvints if this is fixing a broken behavior I think we need to do it. It sounds like Symfony was adding this automatically in the past so this is bringing us back to that behavior.

[GrahamCampbell]

I think Symfony considered it to be a bad idea to automatically set the content type, and actively decided to remove it.

[adam1010]

Sure, trying to guess (or assume) the content type isn't the best idea, but it's much better than having the content-type header just echoed back out based on whatever the client asked for when the content itself isn't actually changing.

For endpoints that deliver non-HTML, devs are used to specifying that manually (because until this recent regression, you didn't have to explicitly set text/html)

return response()->view('sitemap')->header('Content-Type', 'text/xml');

or

return response($bytes, 200,
        ['Content-Type' => 'application/octet-stream', 'Content-Disposition' => 'attachment']
  );