iframe transport isn't transferring any data - php

Question

I'm using jQuery-File-Upload with jQuery-Iframe-Transport to try to get support for older versions of IE.
I've set the forceIframeTransport option to true so that it behaves more or less the same way in all browsers, but I don't seem to get any data back on the server-side regardless of browser when it uses the iframe transport.
I've spat out the request headers server-side and I get back:
array(
Host => "*******"
Connection => "keep-alive"
Content-Length => "0"
Accept => "*/*"
Origin => "**************"
X-Requested-With => "XMLHttpRequest"
User-Agent => "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.57 Safari/537.17"
DNT => "1"
Referer => "***********"
Accept-Encoding => "gzip,deflate,sdch"
Accept-Language => "en-GB,en-US;q=0.8,en;q=0.6"
Accept-Charset => "ISO-8859-1,utf-8;q=0.7,*;q=0.3"
Cookie => "*********"
)
[*****s indicated bleeped out info; you don't need that ;)]
Which look OK, but $_REQUEST is empty (i.e., array()), and the input buffer is empty too:
$handle = fopen('php://input', 'r');
$file_data = '';
while(($buffer = fgets($handle, 4096)) !== false) {
$file_data .= $buffer;
}
fclose($handle); // $file_data = '';
This all worked fine when I wasn't using the iframe-transport but I need IE support... does anyone have any experience with transmitting files using iframes and might know why no data is coming through?
When I use jQuery-File-Upload / js / jquery.iframe-transport.js and force iframe transport it works in Chrome, but the requests don't even make it to the server in IE.
When I use jquery-iframe-transport / jquery.iframe-transport.js and force iframe transport it breaks in Chrome, but that's fine because Chrome supports proper XHR file transfers, and the requests at least hit the server in IE but no data comes through.
I've updated my script to support either transfer method:
if(empty($_FILES)) {
$handle = fopen('php://input', 'r');
$file_data = '';
while(($buffer = fgets($handle, 4096)) !== false) {
$file_data .= $buffer;
}
fclose($handle);
} else {
$file_data = file_get_contents($_FILES['files']['tmp_name'][0]);
}
But again, I still can't seem to get any data in IE regardless of what I do.
When I say "IE", I'm specifically testing in IE 8 right now. I need support back to 7 though. This guy claims support all the way back to IE 6.

Answer 1

After many hours, I've finally tracked down the issue.
First, you need to use the transport plugin that comes bundled with jQuery-file-upload because it was made for it ;) I'm not quite sure why the other one got a step further, but I'll get to that in a minute.
I noticed in IE that I was getting an "access is denied" JavaScript error somewhere in the core jquery library. From what I read online this usually happens when you try to submit to a URL at a different domain, which I wasn't doing, so I dismissed it.
I was comparing what the 2 different transport scripts did differently, when I came to a line that said form.submit() in one version, and form[0].submit() in the other. So I tried adding the [0] and then noticed the "access has denied" error changed to point to that line. So clearly, it didn't like where I was submitting the files to.
I double checked the form.action and the URL still looked fine. Through some Google-fu I discovered that you can also get this error if the event does not originate from the original/native file input element.
I had replaced the native input with a fancy one and then triggered a "fake" 'click' event on the hidden native input. This it didn't like.
Took out my fake upload button and plopped the native one (<input type="file"/> fyi) back in, and now everything works like a charm in all browsers. Huzzah!

Answer 2

For what it's worth ...
I was working with jQuery v1.9.1 doing virus scanning on files synchronously before files are uploaded to the server. If the file had a virus, we WERE returning a HTTP 400, and HTTP 200 if not virus.
The HTTP 400 response caused the IE8 "Access Denied" result.
When I changed server reponse from 400 to 401, the UI worked perfectly.
Again, "For What It's Worth."