I have a user who is using the latest version of OSX and Safari. When he tries to upload a file through a form, it hangs (spinner spinning) but nothing happened. I did some reasearch and found this:
http://airbladesoftware.com/notes/note-to-self-prevent-uploads-hanging-in-safari
This fixed problems in previous versions of Safari, but obviously not Safari 5.
I was wondering if anyone else has any ideas how to resolve this? There was some mentioned of it being related to persistent http connections (thus the fix above) and I am using PHP (but I don't think that matters).
Well I found out that in my case the issue is definitely depending on the file content. When uploading a particular JPG file it fails in 8 from 10 attempts (Safari 5.5.1, but here's the seldom case where IE does a better job;-).
When loading and exporting the JPG file with Mac's Preview creating a new JPG fixes the problem disappears. Unfortunately nothing that helps to fix the problem but maybe worth to give Safari users a hint.
I've had some success sending the connection: close header to solve this issue.
Add
header("connection: close");
to the code that handles the file upload. It doesn't seem to solve the issue 100% but it certainly improves it. note that it's case sensitive: "Connection: close" won't work.
Related
I have an issue with GD not creating a new JPG file, it just fails. No error messages and no indication as to what is happening. This is not new code, it has been in and working for the past six years, but all of a sudden with larger images it has started failing.
As a background this is running on an old server (to be switched off and moved to a new site on PHP8 in a couple of months time) that has PHP5.3.3 with GD version 2.0.34.
The code is creating thumbnails from the high-res image (around 24-30MB) and outputting a series of thumbnails from 150px wide to 1024px wide. It fails on all. I have increased the PHP memory limit on the page to 512MB, and set the GD.JPEG_ignore_warning flag for corrupt JPGs.
But every time with these files, this line:
$src_img = #imagecreatefromjpeg($file_path);
just returns FALSE. But never falls over with an error. The file is definitely there (run the same code with a file of the same name that is <20MB and it works fine) and there is plenty of disc space/memory available for a 60MB file to be processed in memory, so I dont see that that is the issue.
A search of Google, StackOverflow and several other sites has not produced any similar issues.
Can anyone offer any thoughts as to what the issue/solution is? I have been looking at this for two days now, and we need to resolve it - simply using smaller JPG files isn't an option for this.
Thanks to #Lessmore answer above, GD was reporting an invalid JPG file, so a further search revealed this answer on StackOverflow, which solved the problem by reading the JPG from a string, rather than file:
Reading an invalid JPG with GD
Thanks all - as ever!
The following script is trivial and works ok apache without issue
header('Content-Type: image/jpeg');
echo file_get_contents('./photo.jpg');
On NGINX/PHP-FPM I get a blank page. I have tried two different virtual servers. One I created, and the homestead improved box ( https://github.com/Swader/homestead_improved ) which is based on Laravel Homestead.
Error reporting is on, there are no errors. If I remove the header and just use:
echo file_get_contents('./photo.jpg');
I get the binary converted to ASCII and see the strange characters; the file is being loaded correctly.
I thought the issue might be a missing header, so I tried content length:
header('Content-Type: image/jpeg');
$contents = file_get_contents('./photo.jpg');
header('Content-length: ' . strlen($contents));
echo $contents;
This gives a different result: The page never loads, as if the browser never receives all the bytes it's expecting.
If I print strlen($contents) it displays the file size in bytes. PHP is loading the image correctly, but it's never reaching the browser.
The script works on an Apache server so the issue seems to be NGINX or PHP-FPM.
I have tried different images (one 80kb, one 2.2mb), the result is the same. I've also tried readfile instead of file_get_contents.
Update
In Chrome developer tools, the full image is downloaded and shown in the Network tab. The browser is getting the data but it's not displayed.
Your problem lies in process memory. PHP uses a different configuration file when running under PHP-FPM then when running under Apache for instance.
The problem with file_get_contents is that it reads the entire file into memory. In the case of an image file, memory reaches its limit and the http response never completes.
To fix the problem, you can either stream the image using fopen or increase PHP-FPM php's memory limit.
Like Scriptonomy said the memory can be an issue. You can also use readfile
https://secure.php.net/manual/en/function.readfile.php
I've set up an Apache Server as localhost in a openSUSE 13.1 64 bit system and I'm currently testing my PHP scripts.
In Konquerer 4.11.5 everything seems fine, but with Firefox 29.0.1 there is a strange phenomenon:
Every 10th time or so the connection fails. Firefox reports: "Connection determined".
The failed connection is listed neither in error_log nor in access_log.
The error must be quite "early". Because my PHP script output.php calls "itself" via
header("Location: output.php?changed_url");
almost immediately, but the Firefox error is BEFORE output.php is opened for the second time.
I have no idea what to do about this. It's a quite annoying issue.
All answers will be appreciated! Thanks in advance!
I guess you are missing
exit;
after the header() location change.
So you have an open script, firefox redirecting to the next (itself) and still having one open, ... I think firefox doesn't like this kind of loop ;)
Do you have any .htaccess file there? Have you tried using firefox from different OS or computer? I bet it's related to your installation of firefox :) (i ain't pro take it as guess)
I have an issue with safari 5+. When client selects the image file to upload through a simple HTML form the MAC version of Safari 5.1 (so far the only browser I found which is doing this) keeps hanging indefinitely.
I have my upload time and size in php.ini set correctly and it works in all other browsers (FF, Opera even IE!) so I do not suppose I have some rookie mistake in the HTML or PHP.
I have searched through many posts and found a bug report which is related to this issue (https://bugs.webkit.org/show_bug.cgi?id=5760). Also I found several Ajax workarounds but none of them has been the right fit. I am not using Ajax on this page and actually due to redirects I do not want to anyway.
Does anyone know the solution?
Also.... suggestions like adding <? header('Connection: close'); ?> to the file make things worse for Opera.
Edit: April 10, 2013
I still did not figure out why Safari hangs on some image uploads. I am making this edit in case someone has a similar problem. BTW when Safari is ran in the VirtualBox the upload fails every time unlike Firefox or IE which works fine. (perhaps a settings issue?)
I found this workaround which is very easy to implement and so far worked with every mainstream browser I could test. (Source: http://www.atwebresults.com/php_ajax_image_upload/ ) However the original question still stands. Thank you.
A workaround for lighttpd:
$HTTP["useragent"] =~ "Safari" {
$HTTP["useragent"] !~ "Chrome" {
server.max-keep-alive-requests = 0
}
}
Jamis Buck discovered it and I added the config lines.
The second rule avoids restricting keepalives to Chrome which also has the Safari substring.
Courtesy of https://bugs.webkit.org/show_bug.cgi?id=5760
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...