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

Edit report at https://bugs.php.net/bug.php?id=76331&edit=1 ID: 76331 Updated by: cmb@php.net Reported by: Andy_Schmidt at HM-Software dot com Summary: Location header overrides Content-Type -Status: Open +Status: Feedback Type: Bug -Package: HTTP related +Package: IIS related Operating System: Win 2012 PHP Version: 7.2.5 -Assigned To: +Assigned To: cmb Block user comment: N Private report: N New Comment: 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? Previous Comments: ------------------------------------------------------------------------ [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 ------------------------------------------------------------------------ [2018-05-11 20:55:28] cmb@php.net > SAPI is standard IIS 8.5 FastCGI. Thanks. So this is likely an (F)CGI issue (I've tested with Apache mod_php). ------------------------------------------------------------------------ [2018-05-11 20:42:03] Andy_Schmidt at HM-Software dot com >> 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)." ------------------------------------------------------------------------ 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