On Mon, August 22, 2005 2:32 pm, Dan Trainor wrote: > Would the abovementioned use of ForceType also allow one to produce an > image given an HTTP GET query? I was tinkering around with something > in > the past where I wanted to implement something such as: > > <img src="http://example.com/myscript.php?site=1&image=2&something=3";> > > Would what you suggest force the server to return an image for that > given URL, so that the img src specification listed above will work? Yes!!! Sort of! But not exactly that way. See, if you do it with just the ForceType, it will work for MOST browsers. But the $_GET parameters will trip you up, on *some* minor browser versions. I think IE 4 on a Mac was one of them, for images... Or maybe that was for PDFs... Whatever. The permutations of MS IE bugs in this domain are endless. Some stupid minor version of IE will *INSIST* that since your URL: http://example.com/myscript.php?site=1&image=2&something=3 has no .jpg nor .jpeg in it, and it DOES have a .php in it, and it uses GET parameters... [voice-over voice="very small rocks" /] Why, then, it *MUST* be a .php file !!! Then, of course, IE says "I don't know what to do with a .php file!" That version of IE will completely IGNORE your Content-type: header, because Microsoft knows better. After all, way back when, there were a lot of broken web-servers that were not sending a Content-type at all, and the default is text/plain, but the output was HTML and the URL had .htm in it, so Microsoft, instead of correctly rendering broken web servers' documents as HTML source, began getting "smart" about URLs and determined that the way the URL looked was MUCH more important than that Standards-based Content-type: header thingie. :-( :-( :-( MS engineers continue down this false path, to this very day, so your Content-type: image/jpeg is *IGNORED*, the GET parameters mean it CANNOT be an image (in Microsoft's mind) because images are static, and, why, if there's a .php in the URL, well then, it has to be a .php document. If you want your dynamic image to work in *EVERY* browser, do *NOT* give the browser an opportunity to [bleep] up. Make your URL look like this: http://example.com/myscript/site=1/image=2/whatever=3/random=7564634/whatever.jpg Put this in your .htaccess: <Files myscript> ForceType application/x-httpd-php </Files> Use something like this (probably in an include file) to snag the paramters that used to be in $_GET, but are now buried in the URL: <?php $pathinfo = $_SERVER['PATH_INFO']; $parts = explode('/', $pathinfo); $PATH = ''; while (list(, $part) = each($parts)){ $keyvalue = explode('=', $part); switch (count($keyvalue)){ case 0: # do nothing break; case 1: $PATH .= urldecode($keyvalue[0]); break; default: $key = $keyvalue[0]; unset($keyvalue[0]); $value = implode('=', $keyvalue); $_PATH[$key] = urldecode($value); break; } } ?> You will now have $_PATH['site'] and so on. $_PATH['random'] is being set simply to force the stupid IE browser to not re-use the same image from its cache. Change the value randomly every time you display the URL. If you want to get really slick, you could use that rnskit (?) to make $_PATH a superglobal just like $_GET. I ain't done that yet, but it's on my "ToDo" list now. Oh, and the 'whatever.jpg' will be in $PATH (no underscore) so you can use that as a key to determine which filename to use as well. Basically, your ForceType tells the web server that it *IS* a PHP document, but the URL gives Microsoft no opportunity to figure out that it's really a PHP script. Since the site=1 is valid directory name, Microsoft has no choice but to assume that is simply a directory where you store images. It ends in 'whatever.jpg' so IE can ignore the Content-type header (which it will) and it will "know" that the document is a JPEG. If people right-click or if you use Content-type: application/octet-stream, well, IE will "know" to use 'whatever.jpg' in the "Save As..." box, because that's the name of the document. Never mind that there is NO whatever.jpg anywhere on your server's hard drive. :-) In other words, if you want Microsoft Internet Explorer to work right, you have to LIE to it. A lot. Which is only fair, considering how much Microsoft lies to us. :-) PS This same technique, and indeed, that code to build $_PATH is also crucial for dynamic PDFs, dynamic FDFs (and the PDFs embedded within them), dynamic SWF (Ming), etc. Microsoft IE has managed to screw all of these up, one way or another, in various versions over the years. You could waste a lot of time mapping out which versions of which IE mess up what, but it's a LOT easier to just: Make the URL "look" static -- No .php, no ?, and it ends with what LOOKS like a static filename with the 3-letter extension MS uses to determine document type. Use ForceType to convert "script.php" to just "script" Put a random number in all dynamic rich media (image, PDF, SWF, ...) URLs so the IE cache won't work. There was at least one weird bug in Netscape (4.7?) that this technique also squashed. More importantly, more recent versions of Mozilla/Firefox/Safari seem to have actually started acting more like IE in this regard -- Using the URL to determine Content-type instead of the Content-type header. Why take chances? Why give the browser a chance to screw up? The browser authors have proven themselves bug-ridden messes. Take control. Make the URL something that no browser could possible screw up and be done with it. [/soapbox] -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
