Re: Streaming download to IE doesn't work

On Mon, May 28, 2007 10:30 pm, Daniel Kasak wrote: > Hi all. > > I'm streaming a file ( location of which is to be hidden from clients, > hence the need to stream ). Basically I'm doing: Actually, you're forcing a download, rather than streaming it... > session_start(); > // some authentication stuff and figuring out the path goes here > // ... > // ... > $source = "/accounts_reports/" . $_GET['id'] . ".bin"; > header( "Content-Disposition: attachment; filename=\"" . $orig . > "\"" > ); > header( "Content-Length: " .filesize( $source ) ); > header( "Content-Type: application/octet-stream" ); > header( "Pragma: no-cache" ); > header( "Expires: 0" ); > readfile( $source ); Get rid of the headers except for Content-type: until IE is happy. > This works *perfectly* with firefox. It doesn't work at all with > Internet Explorer. Also ( not sure if this matters or not ), the site > is > accessed via https ONLY. > > When I click the link to my download php script, I get a dialog asking > if I want to open or save the file, and then whnatever I click, I get: > > >> Internet Explorer cannot download download.php?id=32 from >> IP_ADDRESS. >> >> Internet Explorer was not able to open this Internet site. The >> requested site is either unavailable or cannot be found. Please try >> again later. I fought with IE quite a bit for various kinds of downloads. Eventually, I gave up on the Content-disposition header, as it just wasn't implemented consistently across browsers -- though this may be all legacy at this point... I blogged about that here: http://richardlynch.blogspot.com/ > However, a quick check of apache's ssl access log shows that IE did in > fact 'find' the site. Also, IE is producing the download dialog, which > suggests that it's 'found' the download.php script fine. Yes, it got the headers just fine. What it does next is anybody's guess, but it might have done: HEAD to get the headers GET without the right authentication to get the content This would probably produce the behaviour you are seeing, especially if your authentication failure does a re-direct to an HTML page -- by which point IE is *very* confused as it's expecting a download. Also, if you don't provide a FULL URL in a Location: header to IE, you'll have authentication problems big-time. > Who knows WTF is wrong and how I can work around it? There's no way to 100% know for sure wtf is wrong with IE as it's closed source, so you have a black box to poke at and see what happens. :-( I found, as in the rant above, that it's best to give IE absolutely NO leeway to make any kind of intelligent decision about what to do -- Give it a URL and headers/content that provide the minimum latitude in false interpretation of RFCs. -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So?