Re: [PHP] Re: Change in 5.2.1 re. parsing of URL
Fergus Gibson wrote: Lewis Kapell wrote: We are already using the Content-type header (I should have mentioned that in my first message). Hmmm. So you have a PHP script that sets the mimetype correctly and then outputs straight PDF data, but the user's browser does not accept it as a PDF because the extension of the script is PHP? I find that strange. It's rare but it does happen. We suspect it's a behavior exhibited by certain browsers in combination with certain firewall settings, or something like that. If you can't find a better solution (something weird is going on in my mind) maybe a work-around is mod_rewrite? You could link to the PHP script with a PDF extension and then rewrite it to the PHP extension behind the scenes. I'll look into that. Thanks for the tip. - Lewis -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Change in 5.2.1 re. parsing of URL
Lewis Kapell wrote: > We are already using the Content-type header (I should have mentioned > that in my first message). Hmmm. So you have a PHP script that sets the mimetype correctly and then outputs straight PDF data, but the user's browser does not accept it as a PDF because the extension of the script is PHP? I find that strange. If you can't find a better solution (something weird is going on in my mind) maybe a work-around is mod_rewrite? You could link to the PHP script with a PDF extension and then rewrite it to the PHP extension behind the scenes. > And to say that the user's browser is misconfigured is no solution, > since we don't have the ability to reconfigure it. If all of our > users were on a local network there would be no problem. But that's > not our situation. I agree it's not a solution, but client misconfiguration is difficult, often impossible, to solve with server-side scripting. If you could identify the misconfiguration, your site could offer a how-to document to instruct users how to configure their software correctly. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Change in 5.2.1 re. parsing of URL
We are already using the Content-type header (I should have mentioned that in my first message). And to say that the user's browser is misconfigured is no solution, since we don't have the ability to reconfigure it. If all of our users were on a local network there would be no problem. But that's not our situation. Thank you, Lewis Kapell Computer Operations Seton Home Study School Fergus Gibson wrote: Lewis Kapell wrote: http://www.mydomain.com/mypage.php/phonypage.pdf In this example there is a PHP script called mypage.php which serves up a PDF. Putting the extra text at the end of the URL makes it appear to the user's browser that the URL ends with '.pdf' rather than '.php'. We introduced this hack at my company because a few users were unable to view pages containing PDF or RTF content, presumably because of some combination of browser and/or firewall settings. This is the proper way to handle this. If it doesn't work, the user's browser is misconfigured. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Change in 5.2.1 re. parsing of URL
Lewis Kapell wrote: > http://www.mydomain.com/mypage.php/phonypage.pdf > > In this example there is a PHP script called mypage.php which serves > up a PDF. Putting the extra text at the end of the URL makes it > appear to the user's browser that the URL ends with '.pdf' rather > than '.php'. We introduced this hack at my company because a few > users were unable to view pages containing PDF or RTF content, > presumably because of some combination of browser and/or firewall > settings. This is the proper way to handle this. If it doesn't work, the user's browser is misconfigured. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php