Rory Browne wrote: >> There are times when one needs to parse a file that ends in .jpg (or >> .jpeg) as PHP. >> >> Specifically, broken browsers (various versions of IE) that ignore >> Content-type: headers and use the URL to determine the MIME type will >> not >> correctly display a URL such as: >> >> http://l-i-e.com/gd_example.php >> >> Said browser will, however, correctly handle: >> http://l-i-e.com/gd_example.jpg > > You sure about that? AFAIK so long as the filename ends on .jpg as > shown by the browser, then you're okay. Provided you use PATH_INFO, > then, you can use http://example.com/make_image.php/dummy.jpg Actually, I have generalized a whole plethora of Microsoft IE bugs in one giant mess as the following truism: Microsoft does not believe in dynamic rich media content. Netscape doesn't always get it right either, btw. It is *possible* that I am mistaken in the case of JPEGs, and http://example.com/make_image.php/dummy.jpg will work on every MSIE browser, and even on every browser that pretends to support JPEGs at all. *HOWEVER* I can guarantee that: http://example.com/make_pdf.php/whatever.pdf?input_to_pdf=42 will *BREAK* MSIE/Adobe launching of the Reader, even though: http://example.com/make_pdf.php/whatever.pdf works just fine. And I can guarantee that Expiration headers with JPEG or PDF breaks some browsers. Now, I could sit here and try to remember every possible combination of URL, mime type, file extension, and query string presence that may or may not break one or more releases of MSIE and/or Netscape (or any other browser) in some way... Or, I could do what I have decided is the better solution: Never give Microsoft the opportunity to screw this up. Ever. Always present MSIE with a URL that the browser *CANNOT*, by definition, believe to be anything more than what I want the browser to believe it is. If it's a JPEG, I'm going to give them a URL like: http://example.com/scriptname/var1=value1/var2=value2/filename.jpg where 'filename.jpg' is what I want MSIE to believe is the name of the JPEG. They cannot even remotely stay close to HTTP spec and believe that that is not a static JPEG on my server. My directory names with = in them might be a bit strange, but it's just a URL to them. If it's a PDF, I'll do the same damn thing with .pdf on the end. There will be no .php in the URL. There will be no ? in the URL. There will be no headers about content expiration for them to ignore, or worse, to fail to deliver content because Microsoft doesn't understand that rich media content *can* expire. That last may be the one Netscapre screwed up. Whatever. I don't care any more which browser screws what up. I ain't gonna let any of them ever mess with me again. I simply refuse to give MSIE the opporunity to waste any more of my valuable time figuring out which of their stupid browsers won't follow the HTTP standard and do what it is supposed to do. I *WILL* hand them a URL indistinguishable from a static URL to content. If it's dynamic content, that URL *will* contain a random string that will force them to re-load the content every page hit. If that ruins their caching system, that's their fault for not accepting expiration on rich media in the first place. Not my problem. I've had it with MSIE (and Netscape too, for that matter) on this issue. The browser makers have repeatedly *failed* to understand dynamic rich media content. I will simply not give them the opporunity, across the board, to screw it up again, because they will not be able to (easily) distinguish my dynamic rich media content from boring static rich media content. Can you tell I'm more than a little irked by browser handling of dynamic rich media content, across the board? This is a systemic browser problem that has remained unaddressed for *YEARS* by the browser makers. Instead, they've focused on oh-so-important issues like the BLINK tag, and adding features no user knows how to use, and adding platform-dependent tags and widgets out the wazoo. Gee, thanks. Since they have repeatedly failed, I'm not willing to give them the opportunity any more to fail. They get a URL that looks just like the URL they *can* handle, for all media types, and I'm done with all their flaky browser inconsistencies in this arena. -- 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
