> There are better ways to do this than parsing .jpg files as PHP. One > obvious one is: > > http://example.org/image.php/foo.jpg I believe this broke on a very very very obscure version of IE -- Maybe even the re-branded IE I ran into one time [shudder]. In theory, it was just IE X.xx.yy, but it turned out to be *different* for some case involving rich media. I cannot for the life of me find the references from my day job four times removed to prove it, mind you, and maybe it was with PDF and not JPEG, but at some point, I just don't want to give browsers (or search engines) *ANY* realistic opportunity to spot ".php" and decide that my dynamic image is inferior/invalid. > Another one that I've seen referenced frequently (especially back when > this was a larger and more common problem) is this: > > http://example.org/image.php?iesucks=foo.jpg In the larger picture of rich media in general, this will fail miserable for dynamic PDFs. If I have to dink around with PATH_INFO for PDFs to behave, I might as well treat my JPEGs with the same code-base and use: http://example.com/image/iesucks/foo.jpg http://example.com/pdf/iesucks/foo.pdf Too many browsers, too many bugs ==> I'm not letting them waste my time any more on their stupidity. I wouldn't recommend that users configure servers to parse *ALL* "*.jpg" in a directory as PHP, of course. Ditto for "*.pdf" But to be sure the browser can't mess up, I'll cheerfully for "image" to be a PHP script and foo.jpg is just in the PATH_INFO, or for a one-off, force "progress_meter.jpg" to be a PHP script. I can't begin to estimate the number of hours I've wasted on browser bugs with rich media where they browser used the URL to do something incredibly stupid instead of just taking the valid data being sent and doing the right thing. -- 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
