Re: Clunked encoding???

From: Date: Sat, 10 May 2003 23:55:04 +0000
Subject: Re: Clunked encoding???
References: 1  Groups: php.general 
Request: Send a blank email to php-general+get-147166@lists.php.net to get a copy of this message
Brian Dunning wrote: > causing this problem. All other IE versions seem to handle it > gracefully, but on Mac OS9 it results in downloaded file inheriting the > name of the php script file handling the request, rather than the value > specified in the http header." Almost for sure it has NOTHING to do with chunked data, and *everything* to do with IE on a Mac being not really IE, but the previous version of Netscape (well, they steal Mozilla, really, I think)... At any rate, if you test "IE version X" on a Mac, you'll get about the same gross behaviour characteristics as "Netscape X+1" on a PC. You do the math. So try it on Netscape on your PC, and I'll bet a dollar you get the same problem. So, now, here's the solution. Don't give the browser *ANY* chance to screw up. *FORCE* your link to end in the filename you want the user to see in that download box. Let's pretend, for the sake of argument, that the filename should be 'starfield.gif' So, make your link be like: <A HREF="http://l-i-e.com/starfield.gif"> http://l-i-e.com/starfield.gif </A> But wait, you say, I need PHP to process that starfield.gif. Try the link above. Look at the stars. Hit reload. Look at the stars again. Yup. Stars moved. That GIF file isn't a GIF file at all. In my .htaccess I have <Files starfield.gif> ForceType application/x-httpd-php </Files> You can see the source code at: http://l-i-e.com/starfield.phps So what really happens is the .htaccess file tells Apache to never mind the damn .gif, that's a PHP script. Apache processes it, and spews out a GIF (see the end of the script). The *browser* on the other hand, has absolutely NO WAY to tell that that isn't a "real" GIF file. The URL has .gif at the end. The server spews out all the right bits to make it look like a GIF, albeit slower than if it were a static file. It is indistinguishable from a static GIF to the browser. That's your goal. Make the browser be INCAPABLE of screwing up. Because if it's *possible* for the browser to screw up, some browser somewhere *will* screw up. But wait, you say, I can't create a PHP file for every single different downloadble URL. That's okay. Create a file named, say, "download" Then, use the ForceType above to force "download" to be a PHP script. Then, tack on the name of the file you want the user to see: http://yourserver.com/download/filename.doc Then, use $PATH_INFO to retrieve the actual name of the file you need to process in your PHP script. Apache *knows* that the "download" isn't a directory and you've told Apache it's a PHP script, so it executes it, and you have the filename.doc (or whatever you want to appear in the download box) as part of the URL, so the browser figures that's what it's getting. There *IS* no filename.doc, just a PHP script named download, but the *browser* can't tell that. Fool the browser. Browsers are stupid anyway. :-) PS There are minor versions of IE (3.x?) on the PC that will actually do the same thing -- They'll ignore the headers and look at the URL to tell what kind of file it's downloading. Stupid browsers.

« previous php.general (#147166) next »