Re: [PHP] Change in 5.2.1 re. parsing of URL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Lucas wrote: | Lewis Kapell wrote: |> Jochem Maas wrote: [snip] |>> this is nothing to do with php - it's down to your webserver settings. |>> |> If this has nothing to do with PHP, maybe you can explain why the |> behavior was broken when I upgraded from 5.2.0 to 5.2.1, and started |> working again the instant I reverted back to 5.2.0. No other |> configuration changes were made on the web server. |> | are you using the save php.ini file? If different, maybe their is | something that changed with the settings in that ini file. | I can confirm that PHP 5.2.1 breaks internal URL rewrites, as we experience it with the blogs like Wordpress and ExpressionEngine; permalinks stopped working, even using the _same_ php.ini file. So my guess is something in PHP changed, probably a regular expression -like function? On the Wordpress support forum I posted the following, inclusing a test environment: /* Last week we, the hosting company I work for, upgraded from PHP version 5.2.0 to 5.2.1. And suddenly customers started complaining about permalinks stopped working and returning 404 errors. I am now trying to find the cause (probably changes in some of PHPs regular expression-like functions), but my guess is the Wordpress developers here know more about the rewriting code of Wordpress than I do to pinpoint it :) For my test purposes I have created two identical application folders with one difference: One of them uses PHP 5.2.0 and the other 5.2.1. They both use the same php.ini file. The phpinfo() information is located here: ~ http://www.vevida.to/php/php520/phpinfo.php ~ http://www.vevida.to/php/php521/phpinfo.php and both Wordpress installations can are located here: ~ http://www.vevida.to/php/php520/index.php ~ http://www.vevida.to/php/php521/index.php As you can see, a permalink like ~ http://www.vevida.to/php/php520/index.php/2007/02/21/lorem-ipsum/ works, and ~ http://www.vevida.to/php/php521/index.php/2007/02/21/lorem-ipsum/ does not. [...] Is this a problem I (or better, the Wordpress developers ;)) can fix by changing some code or functions? Or is this a problem with (some of) the PHP core fuctions which needs to be fixed by the PHP developers? [snipped something about mod_rewrite and ISAPI_Rewrite] */ (http://wordpress.org/support/topic/107133) Looking at this in the test environment, my only conclusion is that something within PHP, or in the pcre functions, has changed. - -- Met vriendelijke groet / Best regards, Jan Reilink VEVIDA Services bv, [EMAIL PROTECTED] Postbus 329, 9700 AH GRONINGEN, +31(0)50 - 5492234 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFF3VWVzmimqimD3mIRAnCYAKCmCgd/zw6d3qgoztsdYGKgvC5AuwCeJMWc eE4HRDKz2lVZCZ2aS55xNxQ= =VM5o -END PGP SIGNATURE- -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Change in 5.2.1 re. parsing of URL
On Mon, February 19, 2007 10:20 am, Lewis Kapell wrote: > There seems to be a behavior change introduced in 5.2.1 and I would > like > to know if it was deliberate. > > A couple of years ago, PHP introduced functionality that made it > possible to use a certain trick. I don't know how to describe this > trick in words, so I will illustrate with an example. > > 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. > > I find that version 5.2.1 breaks this behavior - attempting to visit a > URL such as the above produces a 'page not found' error. Presumably > because it is trying to find the file 'phonypage.pdf' which doesn't > exist. > > My question is, should this be regarded as a bug which might be fixed? > Or is this a deliberate change of behavior? It seems MUCH more likely to be a webserver configuration issue, as PHP has no control over what you are describing, really. The web server chooses to invoke PHP, or not, based on web server configuration. Not aware of any way to mess this one up, mind you, but there it is... So check your httpd.conf (or whatever IIS uses) settings. BTW: There was at least ONE browser way back in time, where the trick you are using never worked anyway. While I doubt that anybody on the planet is still using said browser (we're talking a version 4.x minor IE release, I believe...) you may want to consider the second half of this rant: http://richardlynch.blogspot.com So your URLs will just look like: http://example.com/mypage.pdf and the browser cannot POSSIBLY mess up because as far as the browser can tell, it's just a static PDF file it is getting [*]. For example, this PDF: http://uncommonground.com/events.pdf is generated by this code: http://uncommonground.com/events_pdf.phps and it is just as dynamic as the HTML calendar, from which it springs: http://uncommonground.com/events.htm Some day I plan on combining the two scripts into one, actually, as they are really mostly the same... But that's been on my "ToDo" list for many years now, and is unlikely to get done RSN. * To be pedantic, I should say that the browser cannot screw up any more than it would for a static PDF, as it could still manage to screw up quite a few things even with that... :-( -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Change in 5.2.1 re. parsing of URL
Lewis Kapell wrote: If this has nothing to do with PHP, maybe you can explain why the behavior was broken when I upgraded from 5.2.0 to 5.2.1, and started working again the instant I reverted back to 5.2.0. No other configuration changes were made on the web server. ?? Thank you, Lewis Kapell Computer Operations Seton Home Study School Jochem Maas wrote: Lewis Kapell wrote: There seems to be a behavior change introduced in 5.2.1 and I would like to know if it was deliberate. [snip] this is nothing to do with php - it's down to your webserver settings. are you using the save php.ini file? If different, maybe their is something that changed with the settings in that ini file. Check to see if you had a auto_prepend_file setting that was taking care of extracting that data from the URL and making it usable in the script. I remember doing a hack for something like this that required parsing the $_SERVER['QUERY_STRING'] back a few years ago. -- Enjoy, Jim Lucas Different eyes see different things. Different hearts beat on different strings. But there are times for you and me when all such things agree. - Rush -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Change in 5.2.1 re. parsing of URL
If this has nothing to do with PHP, maybe you can explain why the behavior was broken when I upgraded from 5.2.0 to 5.2.1, and started working again the instant I reverted back to 5.2.0. No other configuration changes were made on the web server. ?? Thank you, Lewis Kapell Computer Operations Seton Home Study School Jochem Maas wrote: Lewis Kapell wrote: There seems to be a behavior change introduced in 5.2.1 and I would like to know if it was deliberate. [snip] this is nothing to do with php - it's down to your webserver settings. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Change in 5.2.1 re. parsing of URL
Lewis Kapell wrote: > There seems to be a behavior change introduced in 5.2.1 and I would like > to know if it was deliberate. > > A couple of years ago, PHP introduced functionality that made it > possible to use a certain trick. I don't know how to describe this > trick in words, so I will illustrate with an example. > > 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. > > I find that version 5.2.1 breaks this behavior - attempting to visit a > URL such as the above produces a 'page not found' error. Presumably > because it is trying to find the file 'phonypage.pdf' which doesn't exist. > > My question is, should this be regarded as a bug which might be fixed? > Or is this a deliberate change of behavior? this is nothing to do with php - it's down to your webserver settings. > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Change in 5.2.1 re. parsing of URL
There seems to be a behavior change introduced in 5.2.1 and I would like to know if it was deliberate. A couple of years ago, PHP introduced functionality that made it possible to use a certain trick. I don't know how to describe this trick in words, so I will illustrate with an example. 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. I find that version 5.2.1 breaks this behavior - attempting to visit a URL such as the above produces a 'page not found' error. Presumably because it is trying to find the file 'phonypage.pdf' which doesn't exist. My question is, should this be regarded as a bug which might be fixed? Or is this a deliberate change of behavior? -- Thank you, Lewis Kapell Computer Operations Seton Home Study School -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
