I've recently migrated servers and found that all $_POST requests on my website are no longer working. The requests always successfully redirect to the 'post' page, but no data is sent and print_r($_POST) always turns up an empty string. I believe this issue has something to do with PHP's settings because the problem occurs over multiple pages which were working fine on the previous server (GET requests seem to still be working fine).
I created a test.php file in my home directory with a very simple POST form to try to rule out any variables.
<?php print_r($_POST); ?>
<form action="test.php" method="POST">
Name: <input type="text" name="name"><br>
<input type="submit">
</form>
the page always prints only an empty the array Array ( )
Any help would be greatly appreciated, I'm sure its something simple but google doesn't seem to have the answer :(
I've realized the issue was in my .htaccess file. My POSTS were being stripped of their extensions and losing all the post data.
this topic php $_POST array empty upon form submission was the most help
Running PhpStorm 2016.3.2, Ubuntu 16.04 with PHP7 and LAMP stack installed and tested.
I seem to have an error in PhpStorm (or somewhere else down the line), whereby clicking 'Submit' in an html form will result in a '404 not found' error, even if the form action path is valid.
I built a very simple application to demonstrate this, however it should be noted that this error has occurred every time I use an html form in PhpStorm so far, even example applications that I know have no errors in code.
The code for my form is as follows
var $form = <<< FORM
<form action='?' method="post">
<p>Enter your number </p>
<input type="text" name="formInput"
maxlength="10">
<input type="submit" name="formSubmit"
value="Submit">
</form>
FORM;
Once 'Submit' is clicked, the 404 error happens. I have tried multiple permeations of form action such as "" and even a variable set to APP_ROOT_PATH, and then just manually typing out the correct path (even a different php file) also with single and double quotes.
The reason I believe these paths to be valid is that simply by clicking in the address window from the 404 error page and hitting enter (thereby going to the path it was trying to get to) the form loads again fine.
I can't get my head around why this might be, if it was a permissions or path error surely I would not be able to access the path from the browser either?
EDIT: Looking at the source code reveals that the action is what I intended it to be. Even copying the url from there and pasting it into the browser will open the correct form. It is just when clicking 'submit' that the 404 error happens. The correct url is also in the address bar on the 404 page.
EDIT 2 : For note, the '?' action in the above code is irrelevant to the issue as the error occurs no matter what correct link I put there, be it "" or the full path.
On our website, sometimes $_POST is relayed empty to the action pages.
This happens for roughly about %1-2 of the forms submitted on a daily basis. This is about 50-100 corrupt form submissions per day currently.
We are certain the data is there on the initial page. We tried sending the same data with $_POST and $_GET at the same time with the exact same values. $_GET reaches the action page all the time, but $_POST can arrive empty.
Often times, this error happens to Webkit besed browsers. Also mobile phone browser seem to be more prone to this.
IE browsers experience this less than the Webkit browsers.
And very rarely it happens to Firefox as well.
Current configuration is like this:
PHP Version 5.2.15
Centos 5
Apache 2.2.3
One thing we are discussing is to upgrade our PHP to 5.3.x.
Does that sound like a reasonable try?
Any suggestions on how we can try to debug this?
UPDATE:
Submission form is as follows:
<form action="submit.php?receiver_user_id=<?php echo $_SESSION['receiver_user_id'];?>&sender_user_id=<?php echo $_SESSION['user_id']; ?>" method="post">
<textarea name="message_text" ></textarea>
<input type="hidden" name="receiver_user_id" value="<?php echo $_SESSION['receiver_user_id'];?>
<input type="hidden" name="sender_user_id" value="<?php echo $_SESSION['user_id']; ?>
<input type="image" name="submit" src="submit.png" value="submit"/>
</form>
Could it be that some sort of input to the form makes the sending fail, or, assuming you judge the 1-2% by empty database entries, makes the storing fail, respectively?
[edit] That sounds stupid... What I meant was, if you have a loop submitting the form 1000 times with the same values, does 1-2% still go empty, or could it be up to what is sent, that the form goes empty?
Adding
<?php header("Connection: close"); ?>
cleared the problem on our end. Apparently this relates to keep-alive and IE. You can read more about it here:
Why does Internet Explorer not send HTTP post body on Ajax call after failure?
I have a simple HTML form, sending a post request to a php script. In IE8, the form only works intermittently - most of the time the PHP script sees an empty $_POST variable.
Here's my code:
<html>
<head>
<title>Post test</title>
</head>
<body style="text-align: center;">
<?php
echo "<pre>".print_r($_POST, TRUE)."</pre>";
?>
<form action="<?php echo $_SERVER['PHP_SELF'] ?>" method="post">
<input type="text" name="name">
<input type="hidden" name="hidden" value="moo" >
<input type="submit" value="Search" >
</form>
</body>
</html>
Sometimes the print_r gives the response you'd expect (i.e. it's populated with the data from the form), most of the time it's empty.
Not being able to use POST is a bit of a problem for web applications - anyone got any ideas what's going on, and how to fix it?
Thanks everyone for wading in on this one.
It turns out the problem lay in an Apache module I had enabled.
It's a module to allow apache to use Windows authentication to identify a user via their Windows User id - mod_auth_sspi
The effect is caused by a known bug, in the module, but with a simple extra directive this can be worked around, until a fix is added in the next update, as described here:
http://sourceforge.net/projects/mod-auth-sspi/forums/forum/550583/topic/3392037
That sounds very very bizarre. Does it happen in other versions of IE as well?
I can't tell you what the problem is, but here are my suggestions on how to diagnose it:
Print $_REQUEST rather than just $_POST, to see if the data is coming in via another method.
Use a tool like Fiddler or Wireshark to track exactly what is actually being sent by the browser.
Fiddler in particular has been very helpful for me a few times (mainly when debugging Ajax code), and will tell you exactly what was posted by the browser. If your web server is localhost, you can also use Fiddler to track what is received before PHP gets its hands on it. If not, you can use wireshark on the server if you have permissions for installing that sort of thing.
In addition to Fiddler, I would have suggested a browser-based tool like Firebug, but I don't know of one for IE that is good enough (The IE dev toolbar doesn't give you details of request and response data, as far as I know).
I'm suspicious that when the script is telling you that $_POST is empty, you did not actually POST the form. You can check by adding print($_SERVER['REQUEST_METHOD']); after your print_r($_POST);
If you are posting a file some of the time (i.e. with a file input) then make sure you set enctype="multipart/form-data" in your <form> element.
Have you checked the generated html? Is it possible that echo $_SERVER['PHP_SELF'] isn't producing the output you're after, which messes up the form html, which messes up the POST?
I've created an upload script in php that takes a file, resizes it, and creates a cropped square thumbnail. The script itself seems to work fine.
However, when I tried to upload an image through Firefox, on clicking the submit button the browser shows the loading animation, but it never calls the script, it just stays on the current page. If don’t upload an image, then the script can be found and is run.
I tried in safari, and I don’t get the same problem, I can upload an image from the form, it will process it and take me the correct page.
I’ve tired just calling a basic script from the form, it just prints out the $_POST and $_FILES, and I get the same result, if an image is present, it won’t get to the script, if no image is present, it runs fine.
I’m just wondering if anyone has any idea what’s going on?
=Update=
Okay, so I’ve still got this problem, I seem to think I’ve found out what’s causing it then, but then I find something that contradicts it completely.
At the moment, I’ve noticed that I can successfully upload after I clear my Firefox cache, but I can only upload one image, then when I try to upload another, I can’t, it just resets the connection after "Loading..." for a bit.
Also, I’ve noticed that I can Ctrl+F5 a few times and get another upload through.
Although there are ways around this, I don’t want to have a form that requires users to clear cookies or refresh every time they need to upload. And as I’ve mentioned before, this error does not occur in IE/Opera/Safari/Chrome.
It seems like Firefox is storing something, I’m not sure what.
Any help would be gratefully appreciated.
If it helps here is the code I’m using.
The HTML Form
<form enctype="multipart/form-data" action="<?php echo $_SERVER["PHP_SELF"]; ?>" method="POST">
<label for="file">Choose a file to upload</label>
<input id="file" name="file" type="file" /><br />
<input type="submit" value="Upload File" name="submit" />
And the PHP:
if (isset($_POST['submit'])) {
echo "Processing...<br/>";
if (isset($_FILES['file']['name'])) {
$file_array = $_FILES['file'];
echo "Uploading...";
upload File($file_array);
echo "...Done";
}
}
The echos are for me to see what’s going on. If none of them are actually being output. So for some reason the form is not being submitted. Which is why it’s not getting to the script. I’ve no idea why though. I’ve got no CSS, or JavaScript errors.
== Update ==
Okay I’ve being trying some more things and still no luck, the HTML, CSS and JavaScript is all valid. I’ve done an IIS Reset, I’ve recreated my Firefox profile. And still now luck.
I was testing it again, and this time I stopped it in the middle of loading (before the connection was reset) and then tried to go to a different page of the website, and the freezing continued, it would still say "Loading..." and "Waiting for localhost...". Not really sure what to make of that, is it some settings that I have? But then why doesn’t it affect other browsers?
== Update ==
As I mentioned below, it seems that AVG Linkscanner/Active surf shield seems to causing this issue, and there are many reports of others having similar problems with it. I updated from AVG Free v9.0.733 to v9.0.790 and I STILL have the same problem. I’m going to browse the AVG support forums and maybe post something over there since it seems to be an AVG issue.
If anyone does have any more insight, please post below. It’s much appreciated :)
Okay, im getting somewhere with this, you may think this is just a stupid mistake but read on.
If i dont have the < html >< body >..etc tags and just have..
<form enctype="multipart/form-data" action="up.php" method="POST">
<label for="file">Choose a file to upload</label>
<input id="file" name="file" type="file" /><br />
<input type="submit" value="Upload File" name="submit" />
</form>
Then i get this issue, where firefox will hang, on form submission.
If i have the correct tags like..
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title></title>
<link href="style.css" rel="stylesheet" type="text/css" />
</head>
<body >
<form enctype="multipart/form-data" action="up.php" method="POST">
<label for="file">Choose a file to upload</label>
<input id="file" name="file" type="file" /><br />
<input type="submit" value="Upload File" name="submit" />
</form>
</body>
</html>
Then it seems that this works. Now this looks simple, but i build my pages up dynamically so i just have one file that contains just the form code that gets included in the page.
Thats as far as ive got, althought having the form code in a separate file should make no difference since its all put together server side.
Sometimes, relative paths are perceived differently by different browsers, not that sure actually but try to specify current directory by prefixing path with ./, eg:
$target_path = "./public/photos/";
Rest of the code looks fine to me.
Just in case you are using the latest FF 3.6 I'm experiencing exactly the same problem, Any form loading a big file (1MB it's enought) seem to block FF upload.
On IE7/Safari/Opera it works.
Then when you right click in FF and view source, it should look exactly like it does in your code above (below "If i have the correct tags like..").
From the xhtml 1.0 specification
HTML 4 defined the name attribute for
the elements a, applet, form, frame,
iframe, img, and map. HTML 4 also
introduced the id attribute. Both of
these attributes are designed to be
used as fragment identifiers.
In XML, fragment identifiers are of
type ID, and there can only be a
single attribute of type ID per
element. Therefore, in XHTML 1.0 the
id attribute is defined to be of type
ID. In order to ensure that XHTML 1.0
documents are well-structured XML
documents, XHTML 1.0 documents MUST
use the id attribute when defining
fragment identifiers on the elements
listed above.
Maybe adding an id to the form could fix your problem.
Maybe shomething wrong with if (isset($_POST['submit'])) { and the variable $_POST['submit'] is not included by FireFox?
<pre>
<?PHP
print_r($_POST);
?>
</pre>
This isn't going to help you much but I am having EXACTLY the same problem. I have even re-installed FF, cleared cache, stripped the code right down (to a very simple form without validation and with all PHP stripped out - both on load and on post back). I have the problem in FF 3.6.13 and have tested against current versions of Safari(win), Chrome, Opera and IE where the code all works perfectly. My code validates as strict XHTML and all the suggestions above are already in there... what's more I am using my local (on the same computer) web site.
MANY thanks for pointing me towards AVG Link scanner... disabling it does fix the problem but that still leaves me thinking FF has a bug as "all" other browsers play nicely with the AVG Link scanner on.