Re: [PHP] Streaming download to IE doesn't work
That's why you comment your code. Take the extra time and put a bit of effort into explaining yourself. Add in a paragraph explaining what's going on, link to whatever solution you found on the web (who knows it might still exist), and just outright bloat it with comments. You might find it annoying now, but I can't tell you how many times I've thanked myself for doing stuff like this when I've revisited old code. You don't need to comment every line, but put a nice hearty paragraph at the beginning of the confusing part and things should be nice and clear to anyone who has to maintain it. "Daniel Kasak" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On Wed, 2007-05-30 at 13:40 -0500, Richard Lynch wrote: > ..snip... >> If I returned to this 2 years later ( or > God forbid, someone else had to look at it ), they wouldn't have a clue > what it was doing, or why. > ..snip .. > Daniel Kasak > IT Developer > NUS Consulting Group > Level 5, 77 Pacific Highway > North Sydney, NSW, Australia 2060 > T: (+61) 2 9922-7676 / F: (+61) 2 9922 7989 > email: [EMAIL PROTECTED] > website: http://www.nusconsulting.com.au -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Streaming download to IE doesn't work
On Wed, May 30, 2007 9:16 pm, Daniel Kasak wrote: > On Wed, 2007-05-30 at 13:40 -0500, Richard Lynch wrote: > >> On Tue, May 29, 2007 6:37 pm, Daniel Kasak wrote: >> > Actually, that blog had absolutely nothing to do with my problem >> > ( thanks for RTFP!). Not only that, but the recommendation that I >> > construct URLs: >> > >> > http://address.com/script/thing=2/this=3/that=4/download.txt >> > >> > is patently ridiculous. >> >> Why? > > It's excessively complex for no actual benefit. It means you have to > have extra code to 'explode' out the various parts of the URL. Even > after reading your description of the code that handles this, it was > non-obvious what it was for. If I returned to this 2 years later ( or > God forbid, someone else had to look at it ), they wouldn't have a > clue > what it was doing, or why. But also, as I noted, this 'solution' is to > a > different problem - the problem of IE not naming downloads properly. > IE > names them properly for me ... it just doesn't download them ( if over > SSL ). Actually, it solves more than just IE not naming them properly. It also solves some versions of IE not opening PDF from FDF links when the user has chosen to not embed PDF reader in browser bug. It also solved a host of other IE bugs over the years. It would not surprise me in the least if it didn't solve your bug as well, actually. IE is just plain flaky with its stupid attempts to "guess" about content type and intent from URL analysis. I'm sorry you found a simple loop to look at the URL and pull the values into an array confusing... :-v TETO -- 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? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Streaming download to IE doesn't work
Sorry ... forgot to comment on this ... On Wed, 2007-05-30 at 13:40 -0500, Richard Lynch wrote: > > ... in particular, adding: > > > > header("Cache-control: private"); > > header("Pragma: public"); > > > > fixed things perfectly. Also note that things worked perfectly with > > normal http access from the start; this is required for streaming > > downloads to IE over *https* > > I highly recommend you now re-test your application in every browser, > every minor version, every release you care about, on every OS > major.minor you care about. Yes I realise this. When I originally discovered the problem ( after developing the app and extensively testing with firefox ), my first impulse was to get the client to use firefox. The response was that the app would be used by 2 of *their* clients, and they insist on using IE6. So based on this, I tested made things work with IE6 and the latest service packs available via Microsoft Update. I have absolutely no interest in supporting every single version of every single browser, at least not for the money I'm being paid, and especially since I've already been told that the app only needs to support IE6 ( and it also already supports firefox ). -- Daniel Kasak IT Developer NUS Consulting Group Level 5, 77 Pacific Highway North Sydney, NSW, Australia 2060 T: (+61) 2 9922-7676 / F: (+61) 2 9922 7989 email: [EMAIL PROTECTED] website: http://www.nusconsulting.com.au -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Streaming download to IE doesn't work
On Wed, 2007-05-30 at 13:40 -0500, Richard Lynch wrote: > On Tue, May 29, 2007 6:37 pm, Daniel Kasak wrote: > > Actually, that blog had absolutely nothing to do with my problem > > ( thanks for RTFP!). Not only that, but the recommendation that I > > construct URLs: > > > > http://address.com/script/thing=2/this=3/that=4/download.txt > > > > is patently ridiculous. > > Why? It's excessively complex for no actual benefit. It means you have to have extra code to 'explode' out the various parts of the URL. Even after reading your description of the code that handles this, it was non-obvious what it was for. If I returned to this 2 years later ( or God forbid, someone else had to look at it ), they wouldn't have a clue what it was doing, or why. But also, as I noted, this 'solution' is to a different problem - the problem of IE not naming downloads properly. IE names them properly for me ... it just doesn't download them ( if over SSL ). -- Daniel Kasak IT Developer NUS Consulting Group Level 5, 77 Pacific Highway North Sydney, NSW, Australia 2060 T: (+61) 2 9922-7676 / F: (+61) 2 9922 7989 email: [EMAIL PROTECTED] website: http://www.nusconsulting.com.au -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Streaming download to IE doesn't work
On Tue, May 29, 2007 6:37 pm, Daniel Kasak wrote: > Actually, that blog had absolutely nothing to do with my problem > ( thanks for RTFP!). Not only that, but the recommendation that I > construct URLs: > > http://address.com/script/thing=2/this=3/that=4/download.txt > > is patently ridiculous. Why? > Anyway, for people who will stumble across > this > bug in the future, check out: > > http://terra.di.fct.unl.pt/docs/php/function.session-cache-limiter.php.htm > > ... in particular, adding: > > header("Cache-control: private"); > header("Pragma: public"); > > fixed things perfectly. Also note that things worked perfectly with > normal http access from the start; this is required for streaming > downloads to IE over *https* I highly recommend you now re-test your application in every browser, every minor version, every release you care about, on every OS major.minor you care about. Because every time you add another header like that to "fix" a browser issue in IE/Firefox/Netscape, you just end up breaking some other browser that interprets things differently. You also need to test with AOL and with various proxy/caching servers in between your site and your browser, as some will, unfortunately, interpret those headers differently. I will wager that if you conduct a full-scale test, you will find at least one combination which is now broken by your fix. I even once ran across a vanity-branded browser (IE re-branded with AT&T logo) where the version numbers in "About IE" were exactly the same, but the browser sure didn't act the same with headers like those -- Probably some kind of buglet in version control, but there it is. The client, AT&T, was not gonna give up their vanity-branded browser. -- 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? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] 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? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Streaming download to IE doesn't work
On Tue, 2007-05-29 at 13:52 +0200, Jochem Maas wrote: > Daniel Kasak wrote: > > Hi all. > > > > > > > Who knows WTF is wrong and how I can work around it? > > without getting into the holywar of download headers, > here is one mans's take/solution: > > http://richardlynch.blogspot.com/2006_06_01_archive.html > > it should contain enough to help you out. > > PS. you might recognize the name from the list > PPS. if you have STFA you would have have found this already, this download > problem comes up regularly. Actually, that blog had absolutely nothing to do with my problem ( thanks for RTFP!). Not only that, but the recommendation that I construct URLs: http://address.com/script/thing=2/this=3/that=4/download.txt is patently ridiculous. Anyway, for people who will stumble across this bug in the future, check out: http://terra.di.fct.unl.pt/docs/php/function.session-cache-limiter.php.htm ... in particular, adding: header("Cache-control: private"); header("Pragma: public"); fixed things perfectly. Also note that things worked perfectly with normal http access from the start; this is required for streaming downloads to IE over *https* -- Daniel Kasak IT Developer NUS Consulting Group Level 5, 77 Pacific Highway North Sydney, NSW, Australia 2060 T: (+61) 2 9922-7676 / F: (+61) 2 9922 7989 email: [EMAIL PROTECTED] website: http://www.nusconsulting.com.au -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Streaming download to IE doesn't work
Daniel Kasak wrote: > Hi all. > > Who knows WTF is wrong and how I can work around it? without getting into the holywar of download headers, here is one mans's take/solution: http://richardlynch.blogspot.com/2006_06_01_archive.html it should contain enough to help you out. PS. you might recognize the name from the list PPS. if you have STFA you would have have found this already, this download problem comes up regularly. > > -- > Daniel Kasak > IT Developer > NUS Consulting Group > Level 5, 77 Pacific Highway > North Sydney, NSW, Australia 2060 > T: (+61) 2 9922-7676 / F: (+61) 2 9922 7989 > email: [EMAIL PROTECTED] > website: http://www.nusconsulting.com.au > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Streaming download to IE doesn't work
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: --- 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 ); --- 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. 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. Now, before I get a litany of 'just use firefox then' responses, rest assured that I would take this approach if I could, but the site is for a customer, and they are in turn doing it for their customers, and this just isn't going to fly. It MUST work with IE. Who knows WTF is wrong and how I can work around it? -- Daniel Kasak IT Developer NUS Consulting Group Level 5, 77 Pacific Highway North Sydney, NSW, Australia 2060 T: (+61) 2 9922-7676 / F: (+61) 2 9922 7989 email: [EMAIL PROTECTED] website: http://www.nusconsulting.com.au -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php