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
Related
I am calling filemtime() from a PHP file executed by POST from a JavaScript/HTML app. It returns the same time stamp for a separate test HTML file every two seconds even when I edit the test file with a text editor and I can see its DTM change in the local file system.
If I reload the entire app (Ctrl+F5), the timestamp reported stays the same. At times (once after 4 hours) the time stamp changes, but I don't know what makes this happen.
The PHP part of my code looks like this:
clearstatcache(true,$FileArg);
$R=filemtime($FileArg);
if ($R===false)
echo "error: file not found";
else
echo $R;
This code is called by synchronous Ajax, given only its PHP filename, using setInterval every 2 seconds.
Windows 10 Home, Apache 2.4.33 running locally for HTTP access, PHP 7.0.30 .
ADDED:
The behavior is the same in Firefox, Chrome, Opera, and Edge.
The results are being cached: http://php.net/manual/en/function.filemtime.php
Note: The results of this function are cached. See clearstatcache() for more details.
It almost sounds like Windows is doing some write caching...
stat() on the other hand has an additional note:
Note:
Note that time resolution may differ from one file system to another.
Maybe worth checking stat output.
edit
Maybe it's a bug, or Windows not playing nice, but you could also do a shell_exec with the Windows command showing DTM.
News: it turns out to be an ordinary bug in my app. I copied my Ajax call and forgot to edit it to apply to the test file. So it applied to one of my app files instead and the DTM only got updated when I edited that app file (FTAdjust.js).
When I specify the correct test file, the DTM updates just fine each time I edit it in another process.
It can sometimes be hard to find one's own bug even when it stares one in the face! I kept looking everywhere else but where the mistake was.
Is there a way to delete a thread from Stack Overflow, since it is irrelevant to others?
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've got a problem with Safari I haven't been able to solve:
<?php
header("Location: ftp://username:password#somedomain.org/somefile.zip");
?>
This code-snippet works in every browser (Fx, Chrome, IE7-9), but not in the latest Safari, which tells me that I don't have permission to view the page (that is, it redirects to the correct page [somedomain.org] with the correct protocol, but does not process the authentication data).
Interestingly it works when I copy it directly to the address bar or when I put in in an <a>-tag an click on it. Is this a Safari bug, or am I missing something here, which the other browsers ignore? And if it's a Safari bug, is there some kind of workaround?
Try:
header('HTTP/1.1 301 Moved Permanently');
header('Location: ftp://username:password#somedomain.org/somefile.zip');
if it doesn't work try :
echo <<< EOF
<META HTTP-EQUIV="Refresh" CONTENT="0;URL=ftp://username:password#somedomain.org/somefile.zip">
EOF;
Or:
header ('Location: ftp://username:password#somedomain.org/somefile.zip');
header ('Content-Length: 0');
The last solution I got from: http://www.ultrashock.com/forum/viewthread/90424/
echo "window.location='ftp://username:password#somedomain.org/somefile.zip';";
Try that JS redirect and see if it's PHP or the request it has a problem with.
You are probably missing some header() info it needs like - header("Status: 200");... A while back header redirect did not work w/o this line in chrome.
You could make the PHP script fetch the file in the background, and serve it to the browser. As in, the PHP script acts as a proxy.
Assuming your download is not larger than your webserver's PHP mem limit, this will be OK.
Benefits:
-There is no redirect.
-You would not be exposing the user/pass in the URL.
If redirecting to the pw protected FTP is your decision, consider the alternatives. There are lots of ways to secure access to a file via http. These days, HTTP performance is about equal to that of FTP (long ago this was not true, and fast sites needed FTP for downloading).
do you receive any error or just not working?
make sure the the output buffer is set correctly in the phpconfig
I had similar problems, and it turned out to be the keychain! If you ever allowed safari, omniweb or opera (or the ftp process in you case) to store the username and password in the keychain for that site, this will be sent to the site instead of the one in the URL. FireFox doesn't do this, so things work as expected there.
I have a website that I've had running on various linux distros so far (debian/redhat mostly)
I've currently set up another machine on a RHEL5 and am having a few issues. My best guess is that it is related to the httpd configuration but I haven't been able to track it down.
Here are the tests I've done to figure the issue out:
-running a simple Jquery .get() command and analysing the resulting data:
.get('testing.php',function(data){
if(data != ''){
alert('not empty');
}
});
with testing.php as follows:
<?php die(); ?>
This would generally never send anything out. It doesn't on my other installs (including another RHEL install) but this time around it is sending the "not empty" alert.
Another example would be:
<?php
header('Content-type: image/png');
echo $PngImageBlob;
?>
With $PnGImageBlob a valid png image blob. The image comes out broken (no errors show though, I get what looks like a valid imageblob if I remove the header)
From both of these I've been wondering if there might not be an issue with apache appending some form of information to the page and thus breaking my data. Or maybe it's a trailing space issue in which case my application is a little too big for me to possibly track them down. Is there some sort of httpd / php configuration option that could help me out here?
I'm currently running php 5.3.6 , Apache/2.2.3 (Red Hat)
It is possible you have some postprocessing being done by Apache: I'd check that you don't have compression turned on in Apache.
I'd also try this: remove the last php tag at the end to make sure there is no output coming after the PNG data. And as previously pointed out, make sure there is absolutely NO whitespace before the first php tag.
<?php
header('Content-type: image/png');
echo $PngImageBlob;
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.