PHP4.1.0 publishing announcement

PHP 4.1.0 Release Announcement PHP 4.1.0 published Announcement (1) After a lengthy QA process, PHP 4.1.0 is finally out. Download at http://www.php.net/downloads.php! PHP 4.1.0 includes several other key improvements:-A new input interface for improved security (read below) A new input interface to improve security-Highly improved performance in general greatly improves performance-Revolutionary performance and stability improvements under Windows. the multithreaded server modules under Windows (ISAPI, Apache, etc .) perform as much as 30 times faster under load! We want to thank Brett Brewer and his team in Microsoft for working with us to improve PHP for Windows. The revolutionary performance and stability of Windows. The multi-threaded server module provides 30 times faster performance. -Versioning support for extensions. right now its barely being used, but the infrastructure was put in place to support separate version numbers for different extensions. the negative side effect is that loading extensions that were built against old versions of PHP will now result in a crash, instead of in a nice clear message. make sure you only use extensions built with PHP 4.1.0. extended translation support. He is still very It is rarely used, but the basic structure is placed to support some extension modules with different versions. The negative impact is that he conflicts with the extended modules of earlier versions. You must be sure to use the php4.1.0 extension module. -Turn-key output compression support supports Turn-key output compression-* LOTS * of fixes and new functions corrected many places and added many functions. As some of you may notice, this version is quite historical, as its first time in history we actually incremented the middle digit! :) The two key reasons for this unprecedented change were the new input interface, and the broken binary compatibility of modules due to the versioning support. {No !! Haha! Translate again later} Following is a description of the new input mechanic. for a full list of changes in PHP 4.1.0, scroll down to the end of this section. the following describes the new input mechanism. For a complete change list, see the following: --------------------------- SECURITY: new input mechanism First and foremost, its important to stress that regardless of anything you may read in the following lines, PHP 4.1.0 * supports * the old input mechanisms from older versions. old applications shocould go on working fine without modification! First of all, it is also the most important thing to emphasize that it is very important to pay enough attention to the following content. Php 4.1.0 supports the old input mechanism. The old application can still run without modification. Now that we have that behind us, lets move on :) the following content is For varous reasons, PHP setups which rely on register_globals being on (I. e ., on form, server and environment variables becoming a part of the global namespace, automatically) are very often exploitable to various degrees. for example, the piece of code: For various reasons, PHP needs to set register_globlas ON (For example, in the bidding form, server, environment variables automatically become part of the global namespace ), they are often disturbed to varying degrees. The following is a piece of code: May be exploitable, as remote users can simply pass on authenticated as a form variable, and then even if authenticate_user () returns false, $ authenticated will actually be set to true. while this looks like a simple example, in reality, quite a few PHP applications ended up being exploitable by things related to this misfeature. you can transmit the authenticated variable in the form to cheat, even if authenticate_user () returns false, $ authent Icated is still set to true. this is just a very simple example. in fact, quite a few programs are spoofed by similar error features While it is quite possible to write secure code in PHP, we felt that the fact that PHP makes it too easy to write insecure code was bad, and weve decided to attempt a far-reaching change, and deprecate register_globals. obviusly, because the vast majority of the PHP code in the world relies on the existence of this feature, we have no plans to Ctually remove it from PHP anytime in the foreseeable future, but weve decided to encourage people to shut it off whenever possible. of course, we can fully write secure PHP code. In fact, PHP makes writing Insecure code very easy and terrible. We decided to try a far-reaching change. Opposed to register_globals. Obviously, because most Code depends on this feature, we cannot really delete it at some point in the future. However, we decided To encourage people To disable it To help users build PHP applications with register_globals being off, weve added several new special variables that can be used instead of the old global variables. there are 7 new special arrays: to help users create PHP applications by disabling register_globals, we have added some new special variables to replace the old global variables. They are 7 new special Arrays: $ _ GET-contains form variables sent through GET contains the variable $ _ POST-contains form variables sent through POST which contains the variable $ _ COOKIE-contains sent through POST HTTP cookie variables contains the HTTP cookie variable $ _ SERVER-contains server variables (e.g ., REMOTE_ADDR) contains server variables (such as REMOTE_ADDR) $ _ ENV-contains the environment variables contains environment variables $ _ REQUEST-a merge of the GET variables, POST variables and Cook Ie variables. in other words-all the information that is coming from the user, and that from a security point of view, cannot be trusted. is a set of GET/POST/Cookie variables, that is, all information from users and security forms. But from the security perspective, they cannot be trusted. $ _ SESSION-contains HTTP variables registered by the session module contains the HTTP variable Now registered by all session modules, other than the fact that these variables contain this special information, theyre also special in another way-theyre automatically global in any scope. this means that you can access them anywhere, without having to global them first. for example: Currently, these variables actually contain special information. They are also automatic global variables in any environment. That is to say, you can access them anywhere without regionalization. For example: function example1 () {print $ _ GET ["name"]; // works, global $ _ GET; is not necessary! // Do not declare $ _ GET as a global variable} wocould work fine! We hope that this fact wowould parse the pain in migrating old code to new code a bit, and were confident its going to make writing new code easier. another neat trick is that creating new entries in the $ _ SESSION array will automatically register them as session variables, as if you called session_register (). this trick is limited to the session module only-for example, setting new entries in $ _ EN V will ** not * perform an implicit putenv (). It runs well. We hope this can make the old code porting easier, and we are confident that it will make it easier to write new code. Another trick is to create a new $ _ SESSION array entry and automatically register them as the session B Variable, just like calling session_register. This tip applies only to the session module. For example, setting a new $ _ ENV entry does not implicitly execute putenv (). PHP 4.1.0 still defaults to have register_globals set to on. its a transitional version, and we encourage application authors, especially public ones which are used by a wide audience, to change their applications to work in an environment where register_globals is set to off. of course, they shocould take advantage of the new features supplied in PHP 4.1.0 that make this transition much easier. PHP 4.1.0 by default, we set register_globals to On. She is a transitional version, and our program is doing it, especially widely accepted. It can change their applications so that register_globals can work even if it is off. Of course, they need to use the new features of PHP 4.1.0 to make the conversion easier. As of the next semi-major version of PHP, new installations of PHP will default to having register_globals set to off. No worries! Existing installations, which already have a php. ini file that has register_globals set to on, will not be affected. only when you install PHP on a brand new machine (typically, if youre a brand new user), will this affect you, and then too-you can turn it on if you choose. in the next incomplete version, the magic will set register_globals to off. don't worry. You have installed php. if you have set register_globals to on in ini, it will not be affected. Only when you install php on a new machine (usually a new user) will it affect you. You can choose to open it. Note: Some of these arrays had old names, e.g. $ HTTP_GET_VARS. these names still work, but we encourage users to switch to the new shorter, and auto-global versions. note: several of these arrays have old names, such as $ HTTP_G.