Bug #76331 [Fbk->Asn]: 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: Feedback +Status: Assigned Type: Bug Package: IIS related Operating System: Win 2012 PHP Version: 7.2.5 Assigned To: cmb Block user comment: N Private report: N New Comment: 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. Previous Comments: ------------------------------------------------------------------------ [2019-09-12 23:48:51] Andy_Schmidt at HM-Software dot com 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 ------------------------------------------------------------------------ [2019-09-12 09:01:33] cmb@php.net 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? ------------------------------------------------------------------------ [2018-06-08 21:28:59] Andy_Schmidt at HM-Software dot com 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. ------------------------------------------------------------------------ [2018-05-11 21:20:47] cmb@php.net > […] 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. ------------------------------------------------------------------------ [2018-05-11 20:57:46] spam2 at rhsoft dot net 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 ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=76331 -- Edit this bug report at https://bugs.php.net/bug.php?id=76331&edit=1