php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #38094 Custom 404 does not receive POST variables
Submitted: 2006-07-13 12:38 UTC Modified: 2007-08-15 08:31 UTC
Votes:7
Avg. Score:4.9 ± 0.3
Reproduced:7 of 7 (100.0%)
Same Version:3 (42.9%)
Same OS:5 (71.4%)
From: mdcore at gmail dot com Assigned:
Status: Not a bug Package: IIS related
PHP Version: 5.1.4 OS: win32
Private report: No CVE-ID: None
 [2006-07-13 12:38 UTC] mdcore at gmail dot com
Description:
------------
I'm using a custom 404 page in IIS to handle a form of mod_rewrite. But if I post a form then the custom 404 does not get the POST variables. this works in IIS5 but not in IIS6. 

Reproduce code:
---------------
formtest.php:
<form method="post" action="non_existant_page.abc">
<input name="test" type="text" value="some stuff" />
<input type="submit" />
</form>

Set this up as a custom 404 page in IIS.
custom404.php:
<pre><?
print_r($GLOBALS);
?></pre>



Expected result:
----------------
non-empty _FORM and REQUEST_METHOD of POST

Actual result:
--------------
empty _FORM and REQUEST_METHOD of GET

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-07-13 12:47 UTC] mdcore at gmail dot com
Why is the PHP ISAPI filter not passing the POST variables to the script?
 [2006-07-13 12:53 UTC] tony2001@php.net
It clearly DOES pass them, as you said it yourself:
>this works in IIS5 but not in IIS6. 
Please report it to Microsoft.
 [2006-07-13 12:57 UTC] mdcore at gmail dot com
Thanks for responding so quickly Tony!

I think it is a bug in the PHP ISAPI filter because if I use a custom 404 ASP page then the POST variables do come through. It's only with PHP pages that it does not work.
 [2006-09-18 20:41 UTC] dangos at gmail dot com
I have confimed this issue, and it _is_ a PHP bug. When presented with an HTTP POST through an IIS 6 custom error handler, PHP receives the raw POST data into php://input, but fails to parse it into $_POST etc.

For comparison, ASP scripts do receive POST variables from IIS 6 custom error handlers, whereas PHP scripts do not. PHP also mangles $_SERVER['QUERY_STRING'] and $_GET and incorrectly reports $_SERVER['REQUEST_METHOD'] as 'GET' in this situation.

I can suggest that the likely reason for the above problems is that when presenting a custom error to a script ISAPI filter IIS6 prepends the error status code to the beginning of the URL (e.g. 404;http://www.example.com/) - this odd format is possibly causing confusion when PHP attempts to process the server variables.
 [2007-08-15 08:31 UTC] jani@php.net
It's hard for PHP to mangle those variables since it sets them to whatever IIS says them to be. So obviously you can't POST to custom 404 anymore. You should use $_REQUEST to refer to variables passed in such cases where you can't be sure where they come from. ;)

IIS bugs are not PHP bugs -> bogus.
 [2013-02-18 00:43 UTC] wahlerit at gmail dot com
I have encountered this issue working with a LAMP server running PHP. No presence 
of Microsoft's IIS.

Custom 404 pages do not seem to receive POST variables. In any URL encoded 
variables present do not get declared and $_SERVER["QUERY_STRING"] is empty. The 
query string however can be determined by looking at $_SERVER["REQUEST_URI"] 
which does come through. It seems that PHP is receiving the information but for 
some reason unknown to me, failing to parse it.

Has anyone been able to figure out how to resolve this?
 [2013-04-18 19:21 UTC] logan at wahlerit dot com
I can think of many reasons why being able to post to a custom 404 is useful in 
ways that would not be handled by what is posted here.

For example if I am running a scholarship website and there is a submission 
deadline, I want to be able to catch data coming from the 404 form to recover 
the submissions and know who tried to submit which application, essay, or 
contact form but got an error that was not their fault instead. Not everyone who 
hits an error actually reports it. Some just get frustrated and leave. I can 
think of one case where a change in Godaddy's server caused such a problem. I 
was able to recover the applications because the webapp being used at the time 
dumped the information into files that it created on the server when it couldn't 
complete the request due to a broken link.
 
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Mon May 17 14:01:24 2021 UTC