I'm working on a web site which creates images online ... there is an SWF which sends variables via post to PHP, and it works fine on my PC but when I test on the server, there are missing variables, specifically the one which contains the colour of the pixels in the image (biggest image is 77 kb). I have set up post_max_size = 32M
Any clue what the problem might be?
There might be some security enforced on PHP to block binary data in POST variables (Suhosin, mod_security, etc.).
Agreed with Michal. Sometimes when something works fine on localhost but not own other sever is also because of short tags. If you have enabled short tags on local server but not on other server, you are bound to receive error or un-expected output. So check with matching of short tags also.
Related
I am using Grégoire's PHP Captcha library, on local host, it is working fine, as of creating images, and sending to browser. But when same code is on remote server, Captcha Image is not being displayed client side. Since in both cases each image request is responded with around 20kB of data, I am sure the image is being downloaded. And from the looks of it, it seems a valid base64 of an image. the only difference I have noticed is that when logging the base64 string, it is usually shorter, around 8kB, while the base64 from localhost is just as much as the real image, ~20kB.
But with my knowledge, I don't know how to use this information. Any Guidelines?
snippet of code:
$captcha = new Gregwar\Captcha\CaptchaBuilder;
$captcha->build(
Config::get('CAPTCHA_WIDTH'),
Config::get('CAPTCHA_HEIGHT')
);
header('Content-type: image/jpeg');
$captcha->output();
Further Info:
I have used wamp on my windows 7, but installed apache2, php5 separately on remote ubuntu 14.04.
Localhost: apache 2.4.9 , php 5.5.12
Remote Server: apache 2.4.7 , php 5.5.9
In both cases No error is being generated whatsoever.
a working base64 from localhost:
data:image/jpeg;base64,/9j/4AAQSkZJRgABAQAAAQABAAD//gA7Q1JFQVRPU ... iiigAooooAKKKKACiiigD//2Q==
which is usually around 20 kbytes long.
a not-working base64 from remote server:
data:image/jpeg;base64,/9j/4AAQSkZJRgABAQEAYABgAAD//gA7Q1JFQVRPU ... I0vQ7A
which is usually around 8 kbytes long.
Edit:
I have fixed it with a workaround, but still not sure about the reason of the problem. here it goes:
In the registrationView.php, I had a tag, of which, the 'src' attribute was set to this non-existing url that triggers the CaptchaBuilder code. So maybe this method does not work on remote config, because of the connection delay??
and what I did is that I replaced the 'src' tag with an ajax request that WAITS for the success and then loads the base64data. If anybody could give a confident comment on this suspicion, hopefully we get to the answer..
Having trouble capturing the following dynamic image on disk, all I get is a 1K size file
http://water.weather.gov/precip/save.php?timetype=RECENT&loctype=NWS&units=engl&timeframe=current&product=observed&loc=regionER
I have setup PHP cURL feature to work just fine on static imagery, but does not work for the above link. Similarly, also copy function, file_put_contents (file_get_contents)...they all work fine for static image. Plenty of references in SO for usage of these PHP functions, so I will not get into details here. Just the copy command:
copy('http://water.weather.gov/precip/save.php?timetype=RECENT&loctype=NWS&units=engl&timeframe=current&product=observed&loc=regionER', 'precip5.png');
Behavior is same, getting precip5.png size 760 bytes, on my windows development box and linux staging box, so can rule OS issues out. Again, all PHP functions do exactly the same thing - generate a file - but empty. Command line curl program is also generating that same junk 1K file.
So, the issue seems to be source and the best I can tell is that it is a dynamic (streaming?) image.
Ideally, I would like this be done in PHP or some command line utility like curl. I am trying to avoid adding java (imageio) dependency just for this...until I absolutely have have to go there...
I am trying to understand the nature of the beast (the image) first ;-)...
The URL you are saving produces HTML output, not the image. You are missing the parameter &print=1
http://water.weather.gov/precip/save.php?timetype=RECENT&loctype=NWS&units=engl&timeframe=current&product=observed&loc=regionER&print=1
We have a web app using Andrew Valums ajax file uploader, if we kick off 5 - 10 image uploads at once, more often then not at least 2 or 3 will result in the same gd error "Corrupt JPEG data"
Warning: imagecreatefromjpeg() [function.imagecreatefromjpeg]:
gd-jpeg, libjpeg: recoverable error: Corrupt JPEG data:
47 extraneous bytes before marker 0xd9 in ....
However this did not happen on our old test server, or local development box's, only on our new production server.
The file size on the server is the same as the original on my local machine, so it completes the upload but I think the data is being corrupted by the server.
I can "fix" the broken files by deleting them and uploading again, or manually uploading via FTP
We had a shared host on Godaddy and just have started to have this issue on a new box (that I set up, so probably explains a lot :) CentOS 5.5+, Apache 2.2.3, PHP 5.2.10
You can see some example good and bad picture here. http://174.127.115.220/temp/pics.zip
When I BinDiffed them I see a consistent pattern the corruption is always 64 byte blocks, and while the distance between corrupted blocks is not constant the number 4356 comes up a lot.
I really think we can rule out the Internet as error checking and retransmission with TCP is pretty reliable, further there seems to be no difference between browser versions, or if I turn anti-virus and firewalls off.
So I'm picking configuration of Apache / PHP?
Some cameras will append some data inside the file that will get interpreted incorrectly (most likely do to character encoding with in the headers).
A solution I found was to read the file in binary mode like so
$fh = fopen('test.jpg', 'rb');
$str = '';
while($fh !== false && !feof($fh)){
$str .= fread($fh, 1024);
}
$test = #imagecreatefromstring($str);
imagepng($test,'save.png');
Well, i think the problem is jpeg-header data, and as far as i know there is nothing to do with it by PHP, i think the problem is your fileuploader, maybe there are some configuration for it that you are missing.
Hmm - a 64 byte corruption?...or did you mean 64 bit?
I'm going to suggest that the issue is in fact as a result of the PHP script. the problem that regularly comes up here is that the script inserts CRLFs into the data stream being uploaded, and is caused by differences between the Window/*nix standards.
Solution is to force the php script to upload in binary mode (use the +b switch for ALL fopen() commands in the php upload). It is safe to upload a text file in binary mode as at least you can still see the data.
Read here for more information on this issue:
http://us2.php.net/manual/en/function.fopen.php
This can be solved with:
ini_set ('gd.jpeg_ignore_warning', 1);
I had this problem with GoDaddy hosting.
I had created the database on GoDaddy using their cPanel interface. It was created as "latin collation" (or something like that). The database on the development server was UTF8. I've tried all solutions on this page, to no avail. Then I converted the database to UTF8, and it worked.
Database encoding shouldn't affect BLOB data (or so I would think). BLOB stands for BINARY Large Object (something...), to my knowledge!
Also, strangely, the data was copied from the dev to production server while the database was still "latin", and it was not corrupted at all. It's only when inserting new images that the problem appeared. So I guess the image data was being fed to MySQL as text data, and I think there is a way (when using SQL) of inserting binary data, and I did not follow it.
Edit: just took a look at the MySQL export script, here it is:
INSERT INTO ... VALUES (..., _binary 0xFFD8FF ...
Anyway, hope this will help someone. The OP did not indicate what solved his problem...
I have a form which sends data with the POST method, about 3000 array keys to be inserted in MySQL like this:
client_add[]=1
client_add[]=3
client_add[]=47
...
The problem is on my localhost on the development server works just fine. On production I only get about 1000 rows, on the localhot it seems to get lost, we confronted the php.ini files and the development server has everything set to more memory than my localhost.
I've run out of ideas.
The size of the post body will be somewhere around 50kb, which is ok as long as the server and/or PHP doesn't enforce a limit. It seems like your production environment enforces such a limit. You should check the entire webserver configuration, and if that is identical as well, compare compile-time defaults. Maybe the phpinfo() call shows more on the actual limits.
PHP has an ini setting which dictates the size of your POST request, you can probably find it in your ini under the name of post_max_size.
Also, if you've got the Suhosin patch installed it will enforce a limit on the number of POST variables you can submit on each request. I think this is around 2000 by default.
PHP 4.4 and PHP 5.2.3 under Apache 2.2.4 on ubuntu.
I am running Moodle 1.5.3 and have recently had a problem when updating a course. The $_POST variable is empty but only if a lot of text was entered into the textarea on the form. If only a short text is entered it works fine.
I have increased the post_max_size from 8M to 200M and increased the memory_limit to 256M but this has not helped.
I have doubled the LimitRequestFieldSize and LimitRequestLine to 16380 and set LimitRequestBody to 0 with no improvement.
I have googled for an answer but have been unable to find one.
HTTP Headers on firefox shows the content size of 3816 with the correct data, so its just not getting to $_POST.
The system was running fine until a few weeks ago. The only change was to /etc/hosts to correct a HELO issue with the exim4 email server.
I can replicate the issue on a development machine that has exim4 not running so I think it is just coincidence.
Thanks for your assistance.
I don't know enough to really provide a useful answer so the following is more a well-educated guess (at least I hope so).
First, you should debug the entire request, either by access_log or for example through firebug. (Good to have Firebug anyway.) To me your problem sounds like a redirect happens in between. I give you an example:
Assume this is your structure:
/form.php
/directory/index.php
This is your form:
<form action="/directory" method="post">
...
</form>
Problem in this case is, that even though /directory is a valid url, Apache will redirect you one more time to /directory/, thus you are loosing your payload (what is supposed to be in $_POST).
Could it be not the size related of the post, but how long the line is before a new line. If they use the Moodle WYSIWYG view the html would just get put into one line with no breaks. If you go into html and hit return around every 1000 characters does it work?
What is the enctype of the form? Could be that it limits the ammount of data send through the form.
You might also want to check the incoming raw $_POST data with:
file_get_contents('php://input');
To make sure their is actually data send.
Got these suggestions here.
It sounds like an Apache or Apache/PHP integration problem. If $_POST is empty it would hint that the http server is not giving the POST information to PHP. If I were you I'd investigate the Apache configuration.
This is obvious, but did you /etc/init.d/apache2 restart ?
Also, the error_log file should show some information about whether the post size exceeded the set limit. Consider increasing your verbosity for troubleshooting the issue