I had the same issue, I find that any flash uploader has HTTPS issues on some clients, mostly Macs. Note that I'm using unsigned SSL certs, I don't know if you're working with signed certs or not.
If you are using a signed cert then I would suggest making sure the host name in the request matches the host name in the cert with a fully qualified path vs a relative one. That will cause certificate validation to fail, beyond that it's most likely a flash issue.
I found that swfupload (I'm usin v2.0) seemed to not work even on IE when using SSL, but knowing that ultimately there would be some degree of SSL issues I opted to simply avoid it all together. It did seem to me that there were some other SSL issues with swfupload; I'll not address that, but I'll explain my work around.
One strange quirk I noticed was that you can use a header to redirect a http URL to a https URL, I simply used php line like so...
<?
// Redirect to a secure socket if non secure is accessed
if (!isset($_SERVER['HTTPS'])) {
header("Location: https://" . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'] );
}
?>
I noticed that some clients would not refuse the socket when being redirected to it. These same clients would fail on a direct request to an https socket. This isn't really a good fix, but it's something I noticed in flash behavior.
I depend highly upon HTTPS so it really does suck that flash doesn't work with https perfectly on all platforms. Basically I ended up having to make the upload form redirect its self to a non secure page for the upload form. It then returns to a secure page when the client is finished uploading. Basically the whole upload process is non https.
If anyone else has any input on this, or has gotten a flash uploader to work with https on Mac/PC, IE/Mozilla then chime in. I've not had any success with it.
I've just been exploring swfupload for a few days now, so my knowledge is not extensive. I can share my findings so far on swfupload and https however. My experiments have been with SWFU 2.0 on a WinXP (x86) machine with Firefox 2 and IE 6, with Flash Player 9,0,47,0 for each. The server is an Apache 2 with SSL, with self-signed cert made with openssl. The server is not a test server, it is in use with an intranet application I've already written.
With both FF and IE, I have HTTPS working fine for me, with relative paths to the flash and upload handler. So far the only way I can make it not work is to use flash_url: with an absolute path that is NOT https.
These examples all work when accessing "https://my.server.com/upload":
In my case the flash movie did not even show up in IE6.
After checking some possible causes for that I came across the solution:
cache preventing headers! Such are:
1. A Cache-Control header with the tokens no-cache, no-store, or max-age=0
2. An Expires header that specifies a time in the past
3. A Vary header that specifies almost anything
In my case it was a "no-cache" cache control header, that caused the headache.
November 25, 2007 - 10:46pm
I had the same issue, I find that any flash uploader has HTTPS issues on some clients, mostly Macs. Note that I'm using unsigned SSL certs, I don't know if you're working with signed certs or not.
If you are using a signed cert then I would suggest making sure the host name in the request matches the host name in the cert with a fully qualified path vs a relative one. That will cause certificate validation to fail, beyond that it's most likely a flash issue.
I found that swfupload (I'm usin v2.0) seemed to not work even on IE when using SSL, but knowing that ultimately there would be some degree of SSL issues I opted to simply avoid it all together. It did seem to me that there were some other SSL issues with swfupload; I'll not address that, but I'll explain my work around.
One strange quirk I noticed was that you can use a header to redirect a http URL to a https URL, I simply used php line like so...
<?
// Redirect to a secure socket if non secure is accessed
if (!isset($_SERVER['HTTPS'])) {
header("Location: https://" . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'] );
}
?>
I noticed that some clients would not refuse the socket when being redirected to it. These same clients would fail on a direct request to an https socket. This isn't really a good fix, but it's something I noticed in flash behavior.
I depend highly upon HTTPS so it really does suck that flash doesn't work with https perfectly on all platforms. Basically I ended up having to make the upload form redirect its self to a non secure page for the upload form. It then returns to a secure page when the client is finished uploading. Basically the whole upload process is non https.
If anyone else has any input on this, or has gotten a flash uploader to work with https on Mac/PC, IE/Mozilla then chime in. I've not had any success with it.
November 26, 2007 - 1:50pm
I've just been exploring swfupload for a few days now, so my knowledge is not extensive. I can share my findings so far on swfupload and https however. My experiments have been with SWFU 2.0 on a WinXP (x86) machine with Firefox 2 and IE 6, with Flash Player 9,0,47,0 for each. The server is an Apache 2 with SSL, with self-signed cert made with openssl. The server is not a test server, it is in use with an intranet application I've already written.
With both FF and IE, I have HTTPS working fine for me, with relative paths to the flash and upload handler. So far the only way I can make it not work is to use flash_url: with an absolute path that is NOT https.
These examples all work when accessing "https://my.server.com/upload":
flash_url: "https://my.server.com/common/swfupload/swfupload_f9.swf"
flash_url: "/common/swfupload/swfupload_f9.swf"
flash_url: "../common/swfupload/swfupload_f9.swf"
This does NOT work when accessing "https://my.server.com/upload":
flash_url: "http://my.server.com/common/swfupload/swfupload_f9.swf"
Other than that I haven't been able to break it on Windows and HTTPS. I'm happy to use my limited knowledge to help if I can, let me know.
Milton
October 31, 2009 - 2:53pm
In my case the flash movie did not even show up in IE6.
After checking some possible causes for that I came across the solution:
cache preventing headers! Such are:
1. A Cache-Control header with the tokens no-cache, no-store, or max-age=0
2. An Expires header that specifies a time in the past
3. A Vary header that specifies almost anything
In my case it was a "no-cache" cache control header, that caused the headache.
Read more on that issue here:
http://blogs.msdn.com/ieinternals/archive/2009/10/02/Internet-Explorer-c...
Tolga Besiktasli