Bug #76331 [Opn]: Location header overrides Content-Type

Edit report at https://bugs.php.net/bug.php?id=76331&edit=1 ID: 76331 User updated by: Andy_Schmidt at HM-Software dot com Reported by: Andy_Schmidt at HM-Software dot com Summary: Location header overrides Content-Type Status: Open Type: Bug Package: HTTP related PHP Version: 7.2.5 Assigned To: cmb Block user comment: N Private report: N New Comment: 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. Previous Comments: ------------------------------------------------------------------------ [2018-05-11 20:30:37] Andy_Schmidt at HM-Software dot com >> 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! ------------------------------------------------------------------------ [2018-05-11 20:21:14] spam2 at rhsoft dot net WTF - a redirect don't need whatever content-type because it should not contain any http body at all ------------------------------------------------------------------------ [2018-05-11 19:37:51] Andy_Schmidt at HM-Software dot com 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. ------------------------------------------------------------------------ [2018-05-11 16:40:40] cmb@php.net 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. ------------------------------------------------------------------------ [2018-05-11 16:09:39] Andy_Schmidt at HM-Software dot com Description: ------------ Setting the "Location" header will set HTTP Status to 302 by default - but ONLY if no explicit Status was set. This is a helpful/reasonable automatism. However, it will also FORCE a Content-Type of "text/html; charset=UTF-8" and adding 224 bytes to the content, disregarding any explicit Content-Type that was set (no matter if set prior or after setting "Location"). HTTP RFCs only state that the content of a redirect "SHOULD" include a forwarding link - but does NOT insist on any Content-Type, nor is this a "MUST". Every worse, PHP even overrides perfectly valid (standards-compliant) "HTML" content-types, such as "application/xhtml+xml". I believe, similar how PHP honors any explicitly set status code, it should also honor any explicitly-set Content-Type and optional supplied content, and only revert to its default Content-Type and content, if NO Content-Type was set. Test script: --------------- http_response_code( 307 ); header( 'Content-Type: application/xhtml+xml' ); header( 'Location: /transient/media/3315-234_a438fc6e0bd719703694e7bfc0b1392ecbb7a6a6_S-2.jpeg' ); header( 'Content-Type: application/xhtml+xml' ); exit; Expected result: ---------------- Response headers should be: ... Content-Length: 0 Content-Type: application/xhtml+xml ... Actual result: -------------- Response headers are: ... Content-Length: 224 Content-Type: text/html; charset=UTF-8 ... ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=76331&edit=1