This appears to be SAPI related, since I get the specified
Content-Type header.  Which SAPI do you use?

Also please check whether it makes a difference, if you set the
$http_response_code via header() instead of using
http_response_code() explicitly.

SAPI is standard IIS 8.5 FastCGI.


Using:
header( 'Location: /transient/media/3315-234_a438fc6e0bd719703694e7bfc0b1392ecbb7a6a6_S-2.jpeg', FALSE, 307 ); 
did NOT alter the outcome.

Also, disabling XDEBUG did not have any effect.

WTF - a redirect don't need whatever content-type because it should not contain any http body at all

>> spam2@rhsoft.net: ...should not contain any http body at all <<

I respect your opinion, however, this is governed by RFCs, which states precisely the OPPOSITE: 
"Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s)." (https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html)

This allows for clients that do NOT perform an automatic redirect. In fact there are scenarios (e.g., request was not "GET" or "HEAD") where the automatic redirect MUST NO occur!

PS: It is also possible to use redirect status 301/302/307 and NOT include a "Location: " header. I've heard of cases where this is used to indicate that the current URL is no longer valid, but automatic forwarding is NOT wanted. 

Instead, content is displayed that might offer up a number of alternative links. And, of course, that content might be served up in whatever Content-Type DIFFERENT from the "text/html" that currently is being hard-substituted.

>> spam2@rhsoft.net: ...should not contain any http body at all <<

Automatic redirection is NOT a requirement, moreover, inclusion of a payload IS explicitly mentioned as being common - exactly the opposite of your opinion. Please note https://tools.ietf.org/html/rfc7231#section-6.4.2:

"The server SHOULD generate a Location header field in the response
   containing a preferred URI reference for the new permanent URI.  The
   user agent MAY use the Location field value for automatic
   redirection.  The server's response payload usually contains a short
   hypertext note with a hyperlink to the new URI(s)."

> SAPI is standard IIS 8.5 FastCGI.

Thanks.  So this is likely an (F)CGI issue (I've tested with
Apache mod_php).

WTF - especially after a POST request succeeded automatic redirects to a confirmation page are common to avoid multiple submits and one yet need to show me any client not following a http redirect unconditional

> […] one yet need to show me any client not following a http
> redirect unconditional

<https://curl.haxx.se/> does not even follow redirects by default.

Anyway, this bug tracker is most certainly not the appropriate
place to discuss the reasonableness of Internet standards and
possibly divergent behavior of clients.  Please let's stick to the
issue at hand, which is that the supplied Content-Type header is
overridden for apparently no good reason.

There are additional complications due to this behavior, in case it helps tracking it down. I just lost a few days tracking down impossible problems in my asynchronous application (claiming that there was additional output after the headers had been written and the buffers had been flush()ed and ob_flushed() )

At the end those turned down to be another side effect of this behavior. Because, NOT ONLY does the system override the "Content-Type", it actually injects a default HTML content with the title "Document Moved", and an H1 of "Object Moved" and a body of "This document may be found here". To make things even worse, it leaves the original "Content-Length" of the image file in place. 

If THAT default HTML redirect content is part of the PHP code, then this would suggest that this behavior is actually native to PHP!

From here things go quickly downhill. Either due to the excessive (= wrong) content length, or due to the previous content type, or maybe PHP still has the original jpeg data stream in a buffer, the FCGI handler will then be handed an extraneous data stream starting with hex FF D8 FF E0 ... which is the JPEG filetype signature. The extra data (after the request had supposedly already completed) causes the web server/FCGI to log a system error and terminate the instance.

I cannot reproduce this with IIS 10 FCGI (PHP 7.2.22).

> Because, NOT ONLY does the system override the "Content-Type",
> it actually injects a default HTML content with the title
> "Document Moved", and an H1 of "Object Moved" and a body of "This
> document may be found here".

This sounds like a Webserver configuration issue.  Is there,
maybe, an error page defined for 307?

No error page for 307 configured at all.
Sorry, have no IIS 10 to test.

Just reran my test with 7.3.8 under IIS 8.5 - tried both with FastCGI and even had it run native CGI through php-cgi-.exe.  I inspected the raw headers in Firefox' Network Tools to confirm that both the Content-Type and Content-Length is "altered".

HTTP/1.1 307 Temporary Redirect
Content-Type: text/html; charset=UTF-8
Location: /62044-206/9edf47546f10b3f4d0b2e9420c5d74f5f2343d53/D.jpeg
Server: Microsoft-IIS/8.5
X-Powered-By: PHP/7.3.8
X-Powered-By: ASP.NET
Date: Thu, 12 Sep 2019 23:38:27 GMT
Content-Length: 231

PS - if I intentionally "garble" the "Location:" header, THEN the Content-Type and Content-Length headers remain unaltered:

HTTP/1.1 307 Temporary Redirect
Content-Type: application/xhtml+xml
Server: Microsoft-IIS/8.5
X-Powered-By: PHP/7.3.8
X-Location: /62044-206/9edf47546f10b3f4d0b2e9420c5d74f5f2343d53/D.jpeg
X-Powered-By: ASP.NET
Date: Fri, 13 Sep 2019 00:11:01 GMT
Content-Length: 0

Naturally, it won't actually redirect, for lack of a new location, but at least it demonstrates that the issue is not based on some "configuration" detail, but rather triggered by the existence of a "Location:" request header.

Well, it seems that this is a known issue that affects older IIS
versions[1], and I don't think we can do anything about it.

[1] <https://forums.iis.net/t/1209573.aspx#2082988>

Indeed, I do suspect the same (I had come across that reference as well last night so I did some targeted testing). However, it actually does NOT seem to be limited to FastCGI, it even happens if I configure IIS to process .PHP through IIS' standard CGI interface to "php-cgi.exe", rather than IIS' FastCGI ISAPI.

I'd be interested to see the headers that Win 2016 generated for my reference.

But I do agree that the injected HTML content, type and length appears to be injected by IIS (possibly up to 2012), not PHP.

On Windows 10 I get (regardless whether the location resource
exists or not):

HTTP/1.1 307 Temporary Redirect
Content-Type: application/xhtml+xml
Location: /cherry.jpg
Server: Microsoft-IIS/10.0
X-Powered-By: PHP/7.2.22
Date: Fri, 13 Sep 2019 13:41:05 GMT
Content-Length: 0