On a private project I stumbled over a weird problem: On page load when the header-information Content-Length reaches 8000 and I add a single character (or more) to the output(e.g. <a>12</a> instead of <a>1</a>), the page will be white and the body (!) of the HTTP-Packet will be empty (also: Content-Length: 0). Debug information (e.g. with PhpConsole for Chrome) is transported correctly, though and when I parse my code via command php index.php no error is thrown and the content of the page is returned correctly.
Since this problem happens at exactly 8000 I guess it is related to a setting made by a human and not some buffer overflow or something similar. Does anyone know that problem and know how to fix it?
Update:
My problem seems to be related to this, which according to the comment is not a bug but a feature called "chunked encoding".
I could quickfix my problem by adding header('Content-Length: '. ob_get_length() ); to the end of my script, but I'd like to understand the problem. So if anyone could explain to me where this problem comes from and how I could fix it permanently and in an appropriate way, that would be great. :)
Related
There are a bunch of questions relating to errors with the count() logic in some phpmyadmin libraries but they all seem slightly different to this one.
I'm at a bit of a loss with this strange behavior in the 'Designer' tab. I'm informed that 'errors have been detected on the server!' and that I should 'look at the bottom of this window', but as you can see from the image there is nothing in the console and the error message is obscured:
After getting this popup every time I opened the Designer tab, I decided to track it down:
... and looking at the line in question, #405, in /usr/share/phpmyadmin/libraries/pmd_common.php, I found:
if (count($min_page_no[0])) {
... but isn't this a perfectly legal use of the count() function?
This is in a library file so how can I debug this? - I tried to var_dump($min_page_no[0]); and reload the page to see what I'm dealing with, but nothing was displayed.
Update your installation of phpMyAdmin.
I believe 4.7.8 addresses this, as evidenced by the release tag on this commit:
https://github.com/phpmyadmin/phpmyadmin/commit/c77cfa7d13370a7f1e3236c5896f89981e61406f
[Edit: And an explanation of why count isn't valid in this case: That particular index isn't always set. If they try to use count() on an array index that isn't set, it'll throw that warning.]
Notice: Yes I did ask this question once before but it got immediatly marked as a duplicate although the linked duplicate had almost nothing to do with my question.
I wrote a php script that is executing my application to download images from the web. And in order to show some kind of progress being made on my website I used flush to echo out some information for the User. Here is my code:
echo '<li class="list-group-item list-group-item-info">Starting to gather data!</li>';
ob_flush();
flush();
$url = $unsplash;
$cmd = $unsplash . ' - ' . $amount;
exec($cmd);
echo '<li class="list-group-item list-group-item-success">Gathering Data Completed</li>';
ob_end_flush();
The code I am using does work without any problem (besides this one) so there is no error there!
Unfortunately every kind of HTML content I write under my php script is being deleted for the duration of the script executing (which sometimes can take up to 5 minutes). But immediately after the script finished the Content beneath reappears. Another thing worth mentioning is, that when I open DevTools in Chrome (F12) during the scipt is being executed is shows nothing!
Am I doing something wrong ? I cant seem to figure it out...
Thank You
I'm not sure, exactly what you mean by "being deleted", but what you need to take into consideration is that output buffering can happen at multiple levels (PHP, Web Server, Client UA, etc..).
If the output from your script does not appear right away, it's likely that you have output_buffering enabled at a higher level (i.e. in your php.ini or other loaded configuration). Because output buffers cascade, they flush at each level. Check your phpinfo() and if you see a value other than 0 for output_buffering, then you need to edit the php.ini file showing in phpinfo() under Loaded Configuration (near the top) and change that value to 0 then restart your parent PHP process.
Another thing to consider is that some browsers won't render some HTML block-level elements like <div>, <ul>, etc... until they are closed. The content may have arrived at the client, but some browsers don't process the rendering of the content until the block level element is complete. So a better way to test that the output is being received on the client end without these variable nuances might be to send a text/plain Content-type header from your PHP to get the HTML rendering stuff out of the way. header('Content-type: text/plain'), if turning off the output_buffering in PHP still doesn't give you the desired result.
I'm having a pretty serious issue since yesterday when I chmoded my main Apache folder (the one with my scripts etc), I think I've certainly done something wrong because some of my PHP pages won't show up and give me a blank page instead of their content, however the other ones still work.
I've checked my Apache logs and I get a "HTTP/1.1 500 273" error on all the files that show a blank page, as I get a standard "HTTP/1.1 200 2876" on all the operational pages.
I don't know what's going on, and I don't even know if it's an Apache2, a PHP, or a simple Chmod-related problem.
EDIT1: I've checked the chmod value of the concerned files to compare them to the ones that work, and they are all the same: 755
EDIT2: In fact there is just one file that is concerned. And the problem is over when I remove this little PHP code that is at its beginning:
<?php
$handle = fopen("./settings.json","r");
$settings = fread($handle, 512);
$jsonsettings = json_decode($settings, true));
fclose($handle);
function alarmonoffcheck () {
if ($jsonsettings['alarmonoff'] == 'on') {
echo("checked");
}
}
?>
I thought there were multiple files that were concerned because this on is used as an include in a main one, and it prevents any other PHP code from being executed, which unables the next includes in the code to work properly.
EDIT3: I've done some debugging and the line that appears to cause the problem is line number 4. I still don't get it, but at least I know where the problem is!
this should fix it:
$jsonsettings = json_decode($settings, true);
I have a problem with 1 of our PHP scripts, it sometime returns truncated message.
The flow:
User call to search.php
The script process the request:
a Connect to the DB
b Build XML using the SimpleXML class
c typeCast the SimpleXML to a string.
d print that string to the client.
The user receive (output to the browser) only part of the message in some cases
after examining this issue, those are the facts I've found:
The maximum length is 19109 chars -> more then that, it getting truncated.
I logged the 2.c typeCast XML string and found out that the log contains the full XML (not truncated!).
other scripts that return shorter/longer response are working fine.
The problem is related somehow to the DB connection:
In order to check if the problem is related to SimpleXML or something with the XML-String, I've printed (output to the browser) a diffrent-hardcoded-XML on #2.d -> it got truncated as well.
Then I tried finding what can cause it (while the diffrent-hardcoded-XML is still there), so I debugged the script using "die;". Then Iv'e found out that only if mysqli_real_connect or mysql_real_connect are called, the return value it truncated.
Any idea on how to solve/debug this issue?
Maybe message #2 give you an answer? In short, PHP manual refuses that such a function barely exists in PHP.
If this is the case, you might see that truncated output because you have implicit flush enabled, so the response is flushed to the browser immidiately during script execution. Than, at some moment script calls mysql_real_connect, which does not exists. This cause script to stop execution, so you see partially formed output. If you have display_errors disabled - you will not see the error message.
So, try enabling error output in your PHP installation (diplay_errors config directive). Another good way to resolve this is checking, if mysql_real_connect really exists with function_exists
Strange issue: PHP runs a nested foreach that generates a string (basically a calendar that shows people's holidays).
This string goes in $data['grid'] and sent to the view. var_dump shows: string(188263)
The string is printed out fine in the webpage when viewed with FF and Chrome but for some reason when viewing with IE6, 8 and 9 (not tested in 7) it crashes the browser every single time; it hangs and nothing ever appears on screen.
IE can show the string when it's printed out in the controller, so before it's passed to the view.
This works fine in IE:
print $str; die;
$data['grid'] = $str;
$this->load->view('conge', $data);
This crashes IE:
//print $str; die;
$data['grid'] = $str;
$this->load->view('conge', $data);
The total "weight" of the page is 192KB and there is no JS running. It feels like a PHP / memory problem but the fact that the "bug" only exist in IE makes little sense.
Any ideas how this can be debugged?
EDIT: When I saved the rendered output from FF in to a static HTML file and load that in IE it sill crashes. The string was printed out without line breaks (loooong) but when I add \n the problem persists. Anyway, one step closer.
EDIT2: It seems to be due to errors in the HTML markup that cause IE to crash (?!). Case closed!
The serverside code cannot crash the browser.
The HTML file generated can crash the browser so you need to examine the outputted HTML carefully.
Point the w3c validation service at the URL and see what it comes back with.
If that yields no results start commenting out large section of the header, then the body etc until you get a successful render then you can investigate a small section of code instead.
Btw I'm assuming 192k includes images, CSS etc else that's a monster HTML file!