I'm a bit confused about this. I'm hoping it's something wildly obvious I've missed! I have a very simple form:
<form class="form-signin" role="form" name="login" method="POST" action="/page">
<input type="password" name="password" />
<input type="submit" value="Sign in" />
</form>
Note: this page lives at /page and is echoed after the following HTML:
On /page I have this at the very top of the file:
<?php
var_dump($_SERVER['REQUEST_METHOD']);
For some reason, it always shows up as GET when I submit this form. If I take the action="/page" part out then it shows up as POST. What am I missing here?
Note: Even when I load the page, then put at exit after the above var_dump() call, it still shows GET.
In the inspector's timeline I see this for the request:
Thanks to the comments to my question I have found the answer to be in apache configuration. It appears that, because the index.php file is inside a folder called page, apache will automatically redirect to the page with a slash on it. This is the default setting as seen in the Apache directorySlash documentation.
As they warn against turning this off, I will just change the url to what I'm posting. Alternatively, of course, I could add a .htaccess file with proper rewrite rules setup.\
Thanks for everyone's help! As a side note, Safari's inspector left me a little wanting in this case. Chrome turned out to be a far better option for testing.
<?php echo $_POST['ss'];?>
<form action="<?php echo $_SERVER['PHP_SELF'];?>" method="post">
<input name="ss" type="text" />
<input type="submit" name="submit">
</form>
This code should print whatever is enter in text box name="ss" when click submit.
But its not printing. Working with method="get" but not with post, What's the problem.
If you're just refreshing the page, do:
action=''
instead of:
action="<?php echo $_SERVER['PHP_SELF'];?>"
Also, add this to line 2 to see what's being stored (if anything) in the $_POST array:
var_dump( $_POST );
Hmm... so it's empty on submit? Try adding this to the top of your php file:
if(empty($_SERVER['CONTENT_TYPE']))
{
$_SERVER['CONTENT_TYPE'] = "application/x-www-form-urlencoded";
}
Okay, now check your php.ini (normally requires sudo or root in /etc):
post_max_size = 8M
variables_order = "EGPCS"
Do you have those two rules set? If so, be careful of how much memory you're allocating. Anything over 2048MB could start to give you trouble, depending on your system specs.
NOTE: If you make changes to your php.ini file and PHP is running as an apache module, you'll need to restart apache. Something along the lines of:
sudo /etc/init.d/httpd restart
I broken my post method once that I set post_max_size the same with upload_max_filesize.
I think that post_max_size must less than upload_max_filesize.
Tested with PHP 5.3.3 in RHEL 6.0
It may be due to rewrite rules in the .htaccess file.Add this condition to your .htaccess file
RewriteCond %{REQUEST_METHOD} !POST [NC]
OR add this line
RewriteRule ^welcome_post.php - [PT]
Finally ...Got it.... Firstly I have an Article folder in my htdocs file with welcome.php as the php file in focus and a main HTML file , whose contents we will be discussing about.
Here's what worked for me..
Turns out the problem was not XAMPP or any of its related files..
The problem was this :
<form action="welcome.php" method="post">
With this code whenever I pressed the submit button, the url redirects to here file:///C:/xampp/htdocs/Article/welcome.php, Which is not what it needs to be..It has to be a localhost link ..So I changed the value of action attribute to localhost form and now it looks like this
<form action="https://localhost/Article/welcome.php" method="post">
That did the trick..Now the submit button redirects to https://localhost/Article/welcome.php , this link..Which is exactly what is needed..
Remember the browser may ask you for some permission issues ..Just accept them it will run fine...
Best of luck..
P.S : This one is for Windows..Hope it will work also in Linux and Mac.
My friend ran into this problem today. The answer was pretty simple - basically, you have to capitalize the POST part of method="POST"
The final result should look like
<?php echo $_POST['ss'];?>
<form action="<?php echo $_SERVER['PHP_SELF'];?>" method="POST">
<input name="ss" type="text" />
<input type="submit" name="submit">
</form>
First make sure that your web service (GET/POST etc) is acting as desired using the Chrome Advanced Rest Client. Then you should check your PHP part.
I solved mine with including following into header.
Content-Type: application/x-www-form-urlencoded
Just use this in the header while making a request and my problem was solved.
<form action="" method="post"> method="post" is important for POST Data.
Use PHP REQUEST instead:
<form action="" method="post">
<input type="email" name="mail">
<input type="submit" name="submit" value="Submit">
</form>
PHP:
if(isset($_REQUEST['submit'])){
$val= $_REQUEST['mail'];
echo $val;
}
use this instead;
$variable_name = $_REQUEST["ss"];
echo $variable_name;
change your IDE ,i use phpstorm ,it's fantastic but when i use dreamweaver it works probably, for test you can run your page directly from wampserver localhost , i change default port of apache and i think problem is from there , if you use phpstorm or change port of apache server change your IDE.
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 have WampServer 2 installed on my Windows 7 computer. I'm using Apache 2.2.11 and PHP 5.2.11. When I attempt to upload any file from a form, it seems to upload, but in PHP, the $_FILES array is empty. There is no file in the c:\wamp\tmp folder. I have configured php.ini to allow file uploads and such. The tmp folder has read/write privileges for the current user. I'm stumped.
HTML:
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
</head>
<body>
<form enctype="multipart/form-data" action="vanilla-upload.php" method="POST">
Choose a file to upload: <input name="uploadedfile" type="file" /><br />
<input type="submit" value="Upload File" />
</form>
</body>
</html>
PHP:
<?php
echo 'file count=', count($_FILES),"\n";
var_dump($_FILES);
echo "\n";
?>
Here's a check-list for file uploading in PHP:
Check php.ini for:
file_uploads = On
post_max_size = 100M
upload_max_filesize = 100M
You might need to use .htaccess or .user.ini if you are on shared hosting and don't have access to php.ini.
Make sure
you’re editing the correct ini file –
use the phpinfo() function to verify your
settings are actually being applied.
Also make sure you don’t
misspell the sizes - it should be 100M not 100MB.
Make sure your <form> tag has the enctype="multipart/form-data" attribute. No other tag will work, it has to be your FORM tag. Double check that it is spelled correctly. Double check that multipart/form-data is surrounded by STRAIGHT QUOTES, not smart quotes pasted in from Word OR from a website blog (WordPress converts straight quotes to angle quotes!). If you have multiple forms on the page, make sure they both have this attribute. Type them in manually, or try straight single quotes typed in manually.
Make sure you do not have two input file fields with the same name attribute. If you need to support multiple, put square brackets at the end of the name:
<input type="file" name="files[]">
<input type="file" name="files[]">
Make sure your tmp and upload directories have the correct read+write permissions set. The temporary upload folder is specified in PHP settings as upload_tmp_dir.
Make sure your file destination and tmp/upload directories do not
have spaces in them.
Make sure all <form>'s on your page have </form> close tags.
Make sure your FORM tag has method="POST". GET requests do not support multipart/form-data uploads.
Make sure your file input tag has a NAME attribute. An ID attribute is NOT sufficient! ID attributes are for use in the DOM, not for POST payloads.
Make sure you are not using Javascript to disable your <input type="file"> field on submission
Make sure you're not nesting forms like <form><form></form></form>
Check your HTML structure for invalid/overlapping tags like <div><form></div></form>
Also make sure that the file you are uploading does not have any non-alphanumeric characters in it.
Once, I just spent hours trying to figure out why this was happening to me all of a sudden. It turned out that I had modified some of the PHP settings in .htaccess, and one of them (not sure which yet) was causing the upload to fail and $_FILES to be empty.
You could potentially try avoiding underscores (_) in the name="" attribute of the <input> tag
Try uploading very small files to narrow down whether it's a file-size issue.
Check your available disk space. Although very rare, it is mentioned in this PHP Manual page comment:
If the $_FILES array suddenly goes mysteriously empty, even though your form seems correct, you should check the disk space available for your temporary folder partition. In my installation, all file uploads failed without warning. After much gnashing of teeth, I tried freeing up additional space, after which file uploads suddenly worked again.
Be sure that you're not submitting the form through an AJAX POST request instead of a normal POST request that causes a page to reload. I went through each and every point in the list above, and finally found out that the reason due to which my $_FILES variable was empty was that I was submitting the form using an AJAX POST request. I know that there are methods to upload files using ajax too, but this could be a valid reason why your $_FILES array is empty.
Source for some of these points:
https://web.archive.org/web/20050426084124/http://getluky.net/2004/10/04/apachephp-_files-array-mysteriously-empty/
As far as the HTML you appear to have set that part up correctly. You already have the enctype="multipart/form-data" which is very important to have on the form.
As far as your php.ini setup, sometimes on systems multiple php.ini files exist. Be sure you are editing the correct one. I know you said you have configured your php.ini file to have file uploads, but did you also set your upload_max_filesize and post_max_size to be larger than the file you are trying to upload? So you should have:
file_uploads = On; sounds like you already did this
post_max_size = 8M; change this higher if needed
upload_max_filesize = 8M; change this higher if needed
Does your directory: "c:\wamp\tmp" have both read and write permissions? Did you remember to restart Apache after you made the php.ini changes?
It is important to add enctype="multipart/form-data" to your form, example
<form action="upload.php" method="post" enctype="multipart/form-data">
Select image to upload:
<input type="file" name="fileToUpload" id="fileToUpload">
<input type="submit" value="Upload Image" name="submit">
</form>
Thank you everybody for the vary comprehensive replies. Those are all very helpful. The answer turned out to be something very odd. It turns out that PHP 5.2.11 doesn't like the following:
post_max_size = 2G
or
post_max_size = 2048M
If I change it to 2047M, the upload works.
I have a same problem looking 2 hours ,is very simple to we check our server configuration first.
Example:
echo $upload_max_size = ini_get('upload_max_filesize');
echo $post_max_size=ini_get('post_max_size');
any type of file size is :20mb, but our upload_max_size is above 20mb but array is null. Answer is our post_max_size should be greater than upload_max_filesize
post_max_size = 750M
upload_max_filesize = 750M
Make sure your input element has a 'name' attribute.
<input type="file" name="uploadedfile" />
If this is missing the $_FILES will be empty.
Here another cause I found:
When using JQuery Mobile and the form attribute data-ajax is set to true, the FILES array will be empty. So set data-ajax to false.
No one mentioned this but it helped me out and not many places on the net mention it.
Make sure your php.ini sets the following key:
upload_tmp_dir="/path/to/some/tmp/folder"
You'll need to check with your webhost if they want you to use an absolute server file path. You should be able to see other directory examples in your php.ini file to determine this. As soon as I set it I got values in my _FILES object.
Finally make sure that your tmp folder and wherever you are moving files to have the correct permissions so that they can be read and written to.
I was struggling with the same problem and testing everything, not getting error reporting and nothing seemed to be wrong.
I had error_reporting(E_ALL)
But suddenly I realized that I had not checked the apache log and voilà!
There was a syntax error on the script...! (a missing "}" )
So, even though this is something evident to be checked, it can be forgotten...
In my case (linux) it is at:
/var/log/apache2/error.log
Check your php.ini for enable_post_data_reading=On , because:
Disabling this option causes $_POST and $_FILES not to be populated. The only way to read postdata will then be through the php://input stream wrapper. (... )
In http://php.net/manual/en/ini.core.php#ini.enable-post-data-reading
If you are trying to upload an array of files then you may need to increase max_file_uploads in php.ini which is by default set to 20
Note: max_file_uploads can NOT be changed outside php.ini. See PHP "Bug" #50684
Another possible culprit is apache redirects. In my case I had apache's httpd.conf set up to redirect certain pages on our site to http versions, and other pages to https versions of the page, if they weren't already. The page on which I had a form with a file input was one of the pages configured to force ssl, but the page designated as the action of the form was configured to be http. So the page would submit the upload to the ssl version of the action page, but apache was redirecting it to the http version of the page and the post data, including the uploaded file was lost.
If your main script is http://Some_long_URL/index.php be carefull to specify the full URL (with explicit index.php and not only http://Some_long_URL) in the action field. Surprisingly, if not, the right script is executed, but with en empty $_FILES !
Do not trust the temp folder location provided by sys_get_temp_dir if you're in a shared hosting environment.
Here is one more thing to check that has not yet been mentioned...
I assumed, naturally, that the folder where my PHP script stored temporary file uploads was /tmp. This belief was reinforced by the fact that echo sys_get_temp_dir() . PHP_EOL; returns/tmp. Also, echo ini_get('upload_tmp_dir'); returns nothing.
To verify that the uploaded file does in fact briefly appear in my /tmp folder, I added a sleep(30); statement to my script (as suggested here) and navigated to my /tmp folder in cPanel File Manager to locate the file. However, no matter what, the uploaded file was nowhere to be found there.
I spent hours trying to determine the reason for this, and implemented every suggestion that's been offered here.
Finally, after searching my website files for the query tmp, I discovered that my site contained other folders named tmp in different directories. I realized that my PHP script was actually writing the uploaded files to .cagefs/tmp. (The "Show Hidden Files" setting must be enabled in cPanel in order to view this folder.)
So, why does the sys_get_temp_dir function return inaccurate info?
Here's an explanation from the PHP.net webpage for sys_get_temp_dir (i.e., the top comment):
If running on a Linux system where systemd has PrivateTmp=true (which
is the default on CentOS 7 and perhaps other newer distros), this
function will simply return "/tmp", not the true, much longer,
somewhat dynamic path.
This SO post delves into the issue, as well:
Stack Overflow: sys_get_temp_dir in shared hosting environment
I ran into the same issue and found that it was my IDE was part of the issue. I was launching the debugger directly from the IDE (PHPStorm) instead of just using the browser directly. The IDE spawned URL was like this:
"...localhost:63342/CB_Upload/index.php?_ijt=j2hcbacqepj87bvg66ncuohvne"
and just using:
"...localhost/CB_Upload/index.php"
worked just fine. My set up is PC / Windows 10 / WAMPSERVER 3.0.6 64bit
I got the same problem and none of theme was my error. Check in your .htaccess file, if you got one, if "MultiViews" are enabled. I had to disable them.
I had similar problem and the issue was in wrong value in htaccess as shamittomar mentioned.
Change php_value post_max_size 10MB to php_value post_max_size 10M
I was empty $_FILES because after <form enctype="multipart/form-data" method="post"> i placed
</div>
<div style="clear:both"></div>
Initial code was like
<span class="span_left">Photos (gif/jpg/jpeg/png) </span>
<form enctype="multipart/form-data" method="post">
<input name="files[]" type="file" id="upload_file" />
<input type="button" id="upload" value="Upload photo" />
</form>
I decided to modify and
<div>
<span class="span_left">Photos (gif/jpg/jpeg/png) </span>
<form enctype="multipart/form-data" method="post">
</div>
<div style="clear:both"></div>
<input name="files[]" type="file" id="upload_file" />
<input type="button" id="upload" value="Upload photo" />
</form>
<div style="clear:both"></div>
So conclusion is that after <form enctype="multipart/form-data" method="post"> must be <input name, type, id and must not be <div> or some other tags
In my situation correct code was
<div>
<span class="span_left">Photos (gif/jpg/jpeg/png) </span>
</div>
<div style="clear:both"></div>
<form enctype="multipart/form-data" method="post">
<input name="files[]" type="file" id="upload_file" />
<input type="button" id="upload" value="Upload photo" />
</form>
<div style="clear:both"></div>
I too had problems with $_FILES empty. The above check-list do not mention MultiViews in .htaccess, httpd.conf or httpd-vhost.conf.
If you have MultiViews set in the options directive for your directory containing the web site, $_FILES will be empty, even though Content-Length header if showing that the file i uploaded.
If you are using JQuery Mobile
Using a multipart form with a file input is not supported by Ajax. In this case you should decorate the parent form with data-ajax="false" to ensure the form is submitted properly to the server.
<form action="upload.php" method="post" enctype="multipart/form-data" data-ajax="false">
Select image to upload:
<input type="file" name="fileToUpload" id="fileToUpload">
<input type="submit" value="Upload Image" name="submit">
</form>
Detach your form form the page you-re using
into a simple php page that has the form and
php code only, and test it like that.
Any bootstrap or java script might clean out
the _FILES[]. That was my case
If you're using AJAX instead of a Form submission, then ensure the request header Content-Type is set to multipart/form-data; boundary=myAwesomeBoundary' where myAwesomeBoundary is the unique string that separates the request body parts. I made the mistake of overriding the Content-Type header by setting it to only multipart/form-data without setting the boundary. The fix was to not override the header but let the browser generate it for me.
I'm tying to send POST data from one site to another (both sites have been developed by us).
The problem is that the POST variables are not available if the page is requested from another domain.
Even if I test it locally, but specify the complete url, the POST data is gone.
So, this will work:
<form method="POST" action="test.php">
But this will not:
<form method="POST" action="http://example.com/test.php">
Here is the HTML for the page:
<html>
<head>
<title></title>
</head>
<body>
<form method="post" action="http://example.com/test.php">
<input type="text" name="request" value="" id="" />
<input type="submit" value="" id="" />
</form>
</body>
</html>
After the comments I got that this should work, I tested it on another server and there everything worked fine indeed. This might have something to do with the fact on the first server https is enabled. But if this is the case, I find it strange that I do get information back but that just the POST data has gone missing.
What you have should work fine - forms came before the same-origin policy - you're allowed to submit to different domains.
If I were to hazard a guess, I'd say there's a 301 or 302 redirect getting in there somehow? Follow the HTTP headers with Firebug for example to be sure.
As others have said, there should be no problem doing this. I would suggest replacing your test.php script with something simple, like this
<?php
echo "<pre>";
var_dump($_POST);
echo "</pre>";
You should find it works, which means the blame lies somewhere in the "real" script...
Maybe also a timesaver:
If you POST to domain.com make sure it doesn't get redirected to www.domain.com.
The redirect doesn't take the POST variables into account , only GETvariables.
If it does get redirected to the www.domain.com add the www. in your POST-action
Thank you. I too found out that redirection to www and https was blocking the performance of my $_POST request.
By changing my action to include https://www.
I fixed my problem.
Thank you