We're seeing an issue that sounds identical to the one reported here:
Intermittent empty $_POST issue
I'm not sure if that question was ever resolved (but I don't have the ability to comment on that post).
It is an extjs form submitted thousands of times a day (json encoded data), with maybe 20 failures getting logged (to a text log we're keeping) each day. We're on Apache, PHP 5.3.14.
We've done extensive searches on users experiencing empty and truncated POST data and tried a number of things, including:
checking value of php://input (also empty/truncated)
checking/increasing config settings like post_max_size
explicitly setting content type
experimenting with keepalive settings
when data is truncated, it is seemingly random (not special characters)
the length of data POSTed doesn't seem to be a factor (truncates at random place, independent of how many fields are being POSTed back)
One potential clue is that when the POST comes back completely empty, it seems to always be with Internet Explorer or Safari. For the ones that are truncated, it doesn't appear to be specific to a particular browser (so it is possible that there are two separate problems at work here).
We're running out of ideas about what to try -- any ideas?
We found something in our app that could have been causing the problem. We had a menu that used javascript and it was doing a form submission, i.e. document.formname.submit(). People were clicking on the menu before the whole page was loaded. This submission had the potential to submit part of a form. This was a javascript HTML issue not server related.
Related
I've already looked through other questions but couldn't find an answer to this specific problem since it seems its all about the Chrome browser.
I stripped down my code to debug this problem and the only thing I'm executing now is loading my database and doing an INSERT.
However it always inserts two rows instead of one row.
Then I tested this with Firefox and there are no problems. I also disabled all my Chrome Extensions and it's still unchanged. I can't figure out what else might be causing this. Like I said, it works in other browsers.
there is some discussion about chrome making multiple requests here
the gist seems to be that there are some things that could cause chrome to make an additional request, including (but not limited to):
link tags with an empty href property <link rel="shortcut" href="">
image, iframe, or scripts tags with an empty or '#' src property <img src="#">
chrome fetching the favicon
do any of those apply?
regardless of what is causing the double GET, a good solution would be to be to follow standard web development best practices: don't change application state as a result of a GET call. Require a POST.
Server side code (e.g. PHP script) does not depend of your browser. So it couldn't behave differently in different browsers.
But yes, in some cases you may have your code executed two times for single page hit.
Lets assume you have a code that inserts new row every time your page has been visited (for example: old-school visits counter). When using Google Chrome you may be surprised, cause you'll get two inserted rows per single page hit. That happens because Google Chrome makes second request to page just for getting favicon.
Other possibility is an weird condition in your code. Eg. if it is chrome, do something else/more
I have a file "host.php" which gives plain text. When I try to run it in browser, once per few refreshes one variable increases by 2, not 1. I tried placing session variable on end, to check if its script error (double var increment) or a http error. Looks like it increases the same way. Also checked Chrome Network debugger. Found one error (with browser trying to load favicon.ico), fixed it and the problem still occurs.
I have seen this question:
What can cause a double page request? which had the same problem, but it wasn't solution for me. I don't use ads or html elements - its plain text.
The result:
The page sometimes loads twice. There is no network errors, like empty src. And its plain text, not html.
The question:
How to fix it? How to prevent page loading twice?
PS: The page never uses POST requests, only get.
I'm not sure is it the correct answer, so I won;t yet mark it as correct.
When I tried the script in Chrome on other device (in Incognito mode), everything worked well (or I just didn't saw...). On my device I'm also using Chrome.
As Incognito mode uses different cookies probably even for each tab (?), it might be fault of some external cookies running (like in linked question, ads could import some). Chrome debugger now only shows 1 cookie, which is PHPSESSID from my site, it looks like its not that.
Afterall, I pressume that its user's device/browser/extensions fault. I also tried disabling Adblock, but that didn't solve the problem.
The last 2-3 days some of our users have been reporting this error. Random pages on our site will output raw binary data. None of the developers can duplicate the issue which comes and goes randomly.
All users reporting the issue have so far been using IE11. The server is Apache 2.4.16 with PHP 5.3.29. There are NO errors being logged by PHP or by Apache related to the issue.
Oddly the HTTP header is embedded in the middle of the data. I can't even fathom a reason that would ever happen. One would expect that if the browser was having issues rendering the content, then it wouldn't be making further requests for more resources to the server and there wouldn't be another HTTP header to show.
We really don't know where to start with this one, we can't tell if it's server, php code, or browser related. Is anyone aware of bugs in Apache or IE that would cause this?
Attached is a screenshot one of the users sent.
I found the bug. The PHP code was generating a 302 redirect, but then also outputting it's normal page content. In certain high load conditions outputting the page could take 3-5 seconds. For some still undetermined reason the output from the first (redirected) request was being munged onto the beginning of the new request before that request's headers, turning the entire thing into garbage.
If anyone knows why THAT behavior - the content of one terminated request being prepended onto a new active request - is happening feel free to answer the question so I can fully mark it solved.
Here's one that might get you scratching your heads - it certainly has me!
I'm using a form to submit content to WordPress' 'update_post_meta' function.
The form itself is pretty simple, just a range of input and textarea fields. On submit the action directs to the same page where some PHP takes over to do validation on the $_POST info before submitting to Wordpress. Now it all works perfectly, except one very strange bug:
Whenever you use the word 'casino' in any of the fields, instead of submitting the form, the page refreshes and throws up a 404 error, even though the address bar shows a perfectly valid URL! I don't believe it's my PHP code as I don't think we get that far in the process, so I'm thinking it's a server thing, but I can't imagine why. This happens on any form across the whole site and I've also got the same result on other sites hosted with the same hosting company (Namecheap, FYI).
So, the question is, can anyone suggest a reason why sending that word in particular to $_POST would break a form and cause that error?
PS. I'm currently solving this using a replace() javascript function so 'casino' never gets sent with the form, but if the 'casion' issue can solved I would be very grateful. It would at least stop me puzzling over it.
This is because the probability of being recognized as spam is high.
Casinos should be used well because there are many websites that cannot be used by the word itself.
Using the language of other countries is one of the ways to promote it by openly saying "[우리카지노][1]" like me.
I hope you will answer your question.
I am experiencing a maddening issue with PHP that I can't seem to resolve. In some cases when a form is posted with a text area or text field and I am also using multi-dimensional arrays for the form field ids (e.g. name="blah[id][5]") the text that was posted in the text area or text field gets mysteriously truncated by PHP at 256 characters with ...cut... at the end of the string. It's definitely happening after the POST, before any other processing and before it's written to the database. I can't find any reference to ...cut... within the PHP source code and we're still unable to reliably reproduce the error. It does not happen all the time. Has anyone encountered this maddening little beast before? We're using Apache 2 and PHP 5.2.6 on CentOS.
Check $HTTP_POST_RAW and/or php://input on the server to see if those are affected as well, and then use something like HTTPFox (in the Mozilla addons repository) to see what's getting sent out on the wire from the client.
As well, see if something like mod_security is active in Apache, which can also re-write data long before it gets anywhere near PHP.