|
|
Posted by "Richard Lynch" on 08/23/05 08:50
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
Navigation:
[Reply to this message]
|