[PHP-DEV] PHP 5.2.2 and PHP 4.4.7 Released!
The PHP development team would like to announce the immediate availability of PHP 5.2.2 and availability of PHP 4.4.7. These releases are major stability and security enhancements of the 5.x and 4.4.x branches, and all users are strongly encouraged to upgrade to it as soon as possible. Further details about the PHP 5.2.2 release can be found in the release announcement for 5.2.2 (http:// www.php.net/releases/5_2_2.php). Details about the PHP 4.4.7 release can be found in the release announcement for 4.4.7 (http:// www.php.net/releases/4_4_7.php). Security Enhancements and Fixes in PHP 5.2.2 and PHP 4.4.7: - Fixed CVE-2007-1001, GD wbmp used with invalid image size (by Ivan Fratric) - Fixed asciiz byte truncation inside mail() (MOPB-33 by Stefan Esser) - Fixed a bug in mb_parse_str() that can be used to activate register_globals (MOPB-26 by Stefan Esser) - Fixed unallocated memory access/double free in in array_user_key_compare() (MOPB-24 by Stefan Esser) - Fixed a double free inside session_regenerate_id() (MOPB-22 by Stefan Esser) - Added missing open_basedir & safe_mode checks to zip:// and bzip:// wrappers. (MOPB-21 by Stefan Esser). - Limit nesting level of input variables with max_input_nesting_level as fix for (MOPB-03 by Stefan Esser) - Fixed CRLF injection inside ftp_putcmd(). (by loveshell[at] Bug.Center.Team) - Fixed a possible super-global overwrite inside import_request_variables(). (by Stefano Di Paola, Stefan Esser) - Fixed a remotely trigger-able buffer overflow inside bundled libxmlrpc library. (by Stanislav Malyshev) Security Enhancements and Fixes in PHP 5.2.2 only: - Fixed a header injection via Subject and To parameters to the mail() function (MOPB-34 by Stefan Esser) - Fixed wrong length calculation in unserialize S type (MOPB-29 by Stefan Esser) - Fixed substr_compare and substr_count information leak (MOPB-14 by Stefan Esser) (Stas, Ilia) - Fixed a remotely trigger-able buffer overflow inside make_http_soap_request(). (by Ilia Alshanetsky) - Fixed a buffer overflow inside user_filter_factory_create(). (by Ilia Alshanetsky) Security Enhancements and Fixes in PHP 4.4.7 only: - XSS in phpinfo() (MOPB-8 by Stefan Esser) While majority of the issues outlined above are local, in some circumstances given specific code paths they can be triggered externally. Therefor, we strongly recommend that if you use code utilizing the functions and extensions identified as having had vulnerabilities in them, you consider upgrading your PHP. Derick Rethans PHP 4.4 Release Master -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Help with the snaps site
Hey! It wasn't THAT scary! Just a table which has the most recent activity on the left side columns. Not too wide. Easy to see which version and the either source or Win32 stuff. And also all the additional files requested. I like the idea. My implementation though. Hmmm. Ok. I agree. Eeek! On 03/05/07, Michael Wallner <[EMAIL PROTECTED]> wrote: Richard Quadling wrote: > How about something along these lines ... > > (Not pretty as I'm crap at the design - sorry). > > http://rquadling.php1h.com/snap.html Eeek! ;) -- Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!" -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: c0il
To commit in cvs a Pear package that already approved by the Pear group. (PHP_Debug) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Re: Help with the snaps site
> Would you be willing to produce the HTML needed for the redesign? Unfortunately my knowledge about HTML and CSS is very limited, so I don't think the page would look very good in case I did it. I would prefer if somebody with more knowledge could do it. I'd be able to do the HTML and CSS on this. -- -- John Mertic"Explaining a joke is like dissecting a frog: you [EMAIL PROTECTED] understand it better, but the frog dies in the process." -Mark Twain -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] ldap extension
Hi, I contacted Stig Venaas who is listed in the php/EXTENSIONS file as being the maintainer of the LDAP extension. I have some patches I would like to provide/apply so that the extension supports LDAP + TLS a little better. Currently there is no way to deal with certificates programatically, and must rely on config files located on the file system that can be difficult to handle in general installation scenarios. Could you please advise how I can go about updating this extension? Regards, Conrad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ldap extension
On 05/04/2007 01:17 PM, Conrad Vermeulen wrote: Hi, I contacted Stig Venaas who is listed in the php/EXTENSIONS file as being the maintainer of the LDAP extension. I have some patches I would like to provide/apply so that the extension supports LDAP + TLS a little better. Currently there is no way to deal with certificates programatically, and must rely on config files located on the file system that can be difficult to handle in general installation scenarios. Could you please advise how I can go about updating this extension? Try contacting Douglas Goldstein (I CCed him), he's the current maintainer of ext/ldap. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] Starting 5.3
Hello internals, i'd like to start 5.3 development from 5.2.2 and have 5.2.* only have security relevant changes and no new features whatsoever. For the biggest changes i'd like to see the following: 1) Adding PECL/Phar as default extension 2) Add open_filename debug info to streams 3) Add object handler get_debug_info 4) Split E_STRICT into E_STRICT and E_DEPRECATED a more complete list can be seen here: http://oss.backendmedia.com/PhP53 Besides 1) all mentioned action points require an API change. The first point could also be done in 5.2.3. As soon as we start with 5.3 development we also need to find a way how to keep track of unmerged changes in 5.2/5.3. Right now a lot of stuff only happens in 5.2 and eventually gets MFB'ed. An idea is to provide an easy way to send commits to bugs.php.net and have them as new category "merge required". Maybe we can have the commit script create a link for this. comments welcome - but please think before writing & only write if you have something to say Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Hello Marcus, Adding a new branch is a huge pita for people distributing binary extension, including our own Windows build and PECL4WIN sites. So perhaps we should wait with adding a new branch since 5.2 is a really nice release, the php5 that works very well :) I think that adding a Phar to the distribution for 5.2.3 is an excellent idea. I also see no reason to stop adding smaller non-api-breaking features to 5.2.x and wait until we have a more compelling reason (more goodies than those listed in points 2-4) to branch out. Edin Marcus Boerger wrote: > Hello internals, > > i'd like to start 5.3 development from 5.2.2 and have 5.2.* only have > security relevant changes and no new features whatsoever. > > For the biggest changes i'd like to see the following: > 1) Adding PECL/Phar as default extension > 2) Add open_filename debug info to streams > 3) Add object handler get_debug_info > 4) Split E_STRICT into E_STRICT and E_DEPRECATED > > a more complete list can be seen here: > http://oss.backendmedia.com/PhP53 > > Besides 1) all mentioned action points require an API change. The first > point could also be done in 5.2.3. > > As soon as we start with 5.3 development we also need to find a way how > to keep track of unmerged changes in 5.2/5.3. Right now a lot of stuff > only happens in 5.2 and eventually gets MFB'ed. An idea is to provide > an easy way to send commits to bugs.php.net and have them as new category > "merge required". Maybe we can have the commit script create a link for > this. > > comments welcome > - but please think before writing > & only write if you have something to say > > Best regards, > Marcus > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On 05/04/2007 07:07 PM, Marcus Boerger wrote: Hello internals, i'd like to start 5.3 development from 5.2.2 and have 5.2.* only have security relevant changes and no new features whatsoever. I'd like to wait for the end of the year (i.e. for the end of PHP4 support period) and then branch off 5_3. We can use this time to make 5_2 as stable as we can and "test" all the new features in HEAD (*). I believe there are a lot of things to do/fix in 5_2 and we should not leave it unattended in favor of 5_3. (*) Yes, I mean everybody should start using HEAD as a development branch and forget that "bah, that Unicode crap again!" attitude. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On 4-May-07, at 11:07 AM, Marcus Boerger wrote: Hello internals, i'd like to start 5.3 development from 5.2.2 and have 5.2.* only have security relevant changes and no new features whatsoever. For the biggest changes i'd like to see the following: 1) Adding PECL/Phar as default extension I really don't think we need phar in core, certainly not enabled by default. If someone can make a good case for including it, I'd love to hear it. 2) Add open_filename debug info to streams What would this mean for performance and memory usage of file ops? 3) Add object handler get_debug_info 4) Split E_STRICT into E_STRICT and E_DEPRECATED Seems like a good idea. +1 So far I don't really see a key reason to move to 5.3, this is a significant change requiring us to maintain an additional branch at least for a few months. This is not a decision we should make lightly, for non-essential reasons. IMHO. Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Hello Ilia, Friday, May 4, 2007, 6:54:33 PM, you wrote: > On 4-May-07, at 11:07 AM, Marcus Boerger wrote: >> Hello internals, >> >> i'd like to start 5.3 development from 5.2.2 and have 5.2.* only >> have >> security relevant changes and no new features whatsoever. >> >> For the biggest changes i'd like to see the following: >> 1) Adding PECL/Phar as default extension > I really don't think we need phar in core, certainly not enabled by > default. If someone can make a good case for including it, I'd love > to hear it. Easier distributing/deployment of stuff and phar even allows to use the packed files as is from within the package or unpacked without any change. We use phar already for pear. Having the extension version that allows the mentioned untouched unpacking feature would help a lot of people. >> 2) Add open_filename debug info to streams > What would this mean for performance and memory usage of file ops? An additional malloc and strcpy on opening and an additional free on closing. We could however limit actual use to --enable-debug builds. >> 3) Add object handler get_debug_info >> 4) Split E_STRICT into E_STRICT and E_DEPRECATED > Seems like a good idea. +1 > So far I don't really see a key reason to move to 5.3, this is a > significant change requiring us to maintain an additional branch at > least for a few months. This is not a decision we should make > lightly, for non-essential reasons. IMHO. > Ilia Alshanetsky Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On 05/04/2007 09:32 PM, Marcus Boerger wrote: I really don't think we need phar in core, certainly not enabled by default. If someone can make a good case for including it, I'd love to hear it. Easier distributing/deployment of stuff and phar even allows to use the packed files as is from within the package or unpacked without any change. We use phar already for pear. Having the extension version that allows the mentioned untouched unpacking feature would help a lot of people. What's the problem with having it in PECL? I'm sure everybody interested in it can get it working in no more than 10 seconds using `pecl install phar`. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On 4-May-07, at 1:32 PM, Marcus Boerger wrote: \For the biggest changes i'd like to see the following: 1) Adding PECL/Phar as default extension I really don't think we need phar in core, certainly not enabled by default. If someone can make a good case for including it, I'd love to hear it. Easier distributing/deployment of stuff and phar even allows to use the packed files as is from within the package or unpacked without any change. We use phar already for pear. Having the extension version that allows the mentioned untouched unpacking feature would help a lot of people. Sure, that's why the Phar is there, I don't contest that it is a useful extension, but so are dozens of others inside PECL. To me it does not mean every extension that is at all useful should be included into the standard distro. If anything having in PECL allows for quicker releases and easier upgrade process, since people will mostly compile it in if it is in core, while pecl will 99% of the time be a shared extension. This means built-in version will require a PHP recompile to upgrade, something most people will not do, making them use older, possibly buggy versions. 2) Add open_filename debug info to streams What would this mean for performance and memory usage of file ops? An additional malloc and strcpy on opening and an additional free on closing. We could however limit actual use to --enable-debug builds. My preference we enable this feature only for debug builds. Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Antony Dovgal wrote: > What's the problem with having it in PECL? > I'm sure everybody interested in it can get it working in no more than > 10 seconds using `pecl install phar`. PECL is great, but it does require a build system with increasingly obsolete set of tools (autoconf-2.13, etc.). Having Phar in the main distro will open up a whole new way to distribute PHP applications which would be a great advantage. The current system of distributing a bunch of PHP files has some shortcomings. Edin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Edink, Just like we build snapshots we can create source packages with pre- built configure scripts for the individual PECL extensions. In fact that's something we need to look into anyway. On 4-May-07, at 1:49 PM, Edin Kadribasic wrote: Antony Dovgal wrote: What's the problem with having it in PECL? I'm sure everybody interested in it can get it working in no more than 10 seconds using `pecl install phar`. PECL is great, but it does require a build system with increasingly obsolete set of tools (autoconf-2.13, etc.). Having Phar in the main distro will open up a whole new way to distribute PHP applications which would be a great advantage. The current system of distributing a bunch of PHP files has some shortcomings. Edin Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On 05/04/2007 09:49 PM, Edin Kadribasic wrote: Antony Dovgal wrote: What's the problem with having it in PECL? I'm sure everybody interested in it can get it working in no more than 10 seconds using `pecl install phar`. PECL is great, but it does require a build system with increasingly obsolete set of tools (autoconf-2.13, etc.). autoconf-2.13 is not required, it's only recommended. Also the same build system is required to build PHP, so this argument looks bogus to me. Having Phar in the main distro will open up a whole new way to distribute PHP applications which would be a great advantage. The current system of distributing a bunch of PHP files has some shortcomings. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Antony Dovgal wrote: > On 05/04/2007 09:49 PM, Edin Kadribasic wrote: >> Antony Dovgal wrote: >>> What's the problem with having it in PECL? >>> I'm sure everybody interested in it can get it working in no more than >>> 10 seconds using `pecl install phar`. >> >> PECL is great, but it does require a build system with increasingly >> obsolete set of tools (autoconf-2.13, etc.). > > autoconf-2.13 is not required, it's only recommended. > Also the same build system is required to build PHP, so this argument > looks bogus to me. PHP source tarballs come with configure scripts pre-built so auto tools (and very old one at that) are not needed. They are for the pecl installs. I really don't understand the objection. We have added the extensions to the core before when we want to promote a certain technology. Edin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On 05/04/2007 10:06 PM, Edin Kadribasic wrote: Antony Dovgal wrote: On 05/04/2007 09:49 PM, Edin Kadribasic wrote: Antony Dovgal wrote: What's the problem with having it in PECL? I'm sure everybody interested in it can get it working in no more than 10 seconds using `pecl install phar`. PECL is great, but it does require a build system with increasingly obsolete set of tools (autoconf-2.13, etc.). autoconf-2.13 is not required, it's only recommended. Also the same build system is required to build PHP, so this argument looks bogus to me. PHP source tarballs come with configure scripts pre-built so auto tools (and very old one at that) are not needed. They are for the pecl installs. You need only autoconf and it's really easy to install. I really don't understand the objection. We have added the extensions to the core before when we want to promote a certain technology. I object because I believe extensions should be moved from core to PECL, not the other way round. If you don't like PECL or think it's too difficult to use, let's make it easy enough for all. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Antony Dovgal wrote: [snip] >> I really don't understand the objection. We have added the extensions to >> the core before when we want to promote a certain technology. > > I object because I believe extensions should be moved from core to PECL, > not the other way round. > If you don't like PECL or think it's too difficult to use, let's make it > easy enough for all. Its a noble goal, but lets be realistic. Having and extension in the core package is always going to be easier than installing it as an external package. There is also how wide spread usage of something we want to get. I think that Phar is going to be useful only if its universally available in the PHP installs, and I think that would a good thing for PHP. Edin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On 05/04/2007 10:16 PM, Edin Kadribasic wrote: Antony Dovgal wrote: [snip] I really don't understand the objection. We have added the extensions to the core before when we want to promote a certain technology. I object because I believe extensions should be moved from core to PECL, not the other way round. If you don't like PECL or think it's too difficult to use, let's make it easy enough for all. Its a noble goal, but lets be realistic. Having and extension in the core package is always going to be easier than installing it as an external package. Both ways are easy enough for me. Moreover, I think adding an extension using PECL is much more easier than recompiling&reinstalling PHP. There is also how wide spread usage of something we want to get. I think that Phar is going to be useful only if its universally available in the PHP installs, and I think that would a good thing for PHP. This is valid for any other PECL module. Most of the extensions we have are useful and good things. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Edin Kadribasic wrote: Antony Dovgal wrote: What's the problem with having it in PECL? I'm sure everybody interested in it can get it working in no more than 10 seconds using `pecl install phar`. PECL is great, but it does require a build system with increasingly obsolete set of tools (autoconf-2.13, etc.). Having Phar in the main distro will open up a whole new way to distribute PHP applications which would be a great advantage. The current system of distributing a bunch of PHP files has some shortcomings. Yes, to me the question is only if we want to give the message that software producers should be able to expect phar to be there on 99% of the systems. Thats the only way that phar has a good chance of really taking off as a php code distribution approach. I personally think that it really improves the distribution process a lot to make this widely available. So I would say yes, add it to core, just like we added ext/json because we feel that this is technology people should be able to rely on. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On Fri, May 4, 2007 1:09 pm, Antony Dovgal wrote: > If you don't like PECL or think it's too difficult to use, let's make > it easy enough for all. How easy is it for an average user on a shared host that needs X, to use pecl to get X, without an intervention by the webhost? I know y'all don't have this issue; But a few zillion PHP developers do. -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On 4-May-07, at 3:14 PM, Lukas Kahwe Smith wrote: Yes, to me the question is only if we want to give the message that software producers should be able to expect phar to be there on 99% of the systems. Thats the only way that phar has a good chance of really taking off as a php code distribution approach. It sounds like the merits of having phar is would only be apparent after it is included in the core and everyone starts using it because of that. This won't happen simply because most software producers can't rely on extensions that are only available in version X. Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Help with the snaps site
On Fri, May 4, 2007 4:49 am, Richard Quadling wrote: > Hey! It wasn't THAT scary! Just a table which has the most recent > activity on the left side columns. > > Not too wide. > > Easy to see which version and the either source or Win32 stuff. > > And also all the additional files requested. > > I like the idea. My implementation though. Hmmm. Ok. I agree. > > Eeek! Worked for me. [shrug] I was able to see what I needed, find what I wanted, and was not confused by what was there. And let's face it, not confusing me is a major accomplishment :-) -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Hello Ilia, Friday, May 4, 2007, 9:24:08 PM, you wrote: > On 4-May-07, at 3:14 PM, Lukas Kahwe Smith wrote: >> Yes, to me the question is only if we want to give the message that >> software producers should be able to expect phar to be there on 99% >> of the systems. Thats the only way that phar has a good chance of >> really taking off as a php code distribution approach. > It sounds like the merits of having phar is would only be apparent > after it is included in the core and everyone starts using it because > of that. This won't happen simply because most software producers > can't rely on extensions that are only available in version X. So we stop developing PHP 6 immediately, right? Ah no it is the reason people like you don't MFB. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On Fri, May 4, 2007 12:46 pm, Ilia Alshanetsky wrote: 2) Add open_filename debug info to streams >> >>> What would this mean for performance and memory usage of file ops? >> >> An additional malloc and strcpy on opening and an additional free >> on closing. We could however limit actual use to --enable-debug >> builds. > > My preference we enable this feature only for debug builds. There might be users for whom debug info in production is way more important than raw performance... I dunno how expensive (malloc + strcopy + free) is, but it doesn't seem to this naive reader like it's going to swamp a server, if somebody who knows what they are doing wants that on even in production. I could easily be under-estimating the expense, but it just seems like there's a lot more PHP scripts that need a lot more better debugging code more than they need raw performance. I'm not claiming that having this available will stop any idiots from writing bad code, but it might help a couple smart folks write better code. -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On 05/04/2007 11:22 PM, Richard Lynch wrote: On Fri, May 4, 2007 1:09 pm, Antony Dovgal wrote: If you don't like PECL or think it's too difficult to use, let's make it easy enough for all. How easy is it for an average user on a shared host that needs X, to use pecl to get X, without an intervention by the webhost? It's the same for those who don't have root privileges - you can't add an extension without a help from your sysadmin and it does not depend whether the extension is in core or in PECL. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Hello Richard, exactly the point. Most developers here can easily compile PHP on their own and typically never face a situation where that is no option or not possible at all. Believe it or not. Stuff in PECL is not being used. Not by the majority of PHP users that rely on prebuild/preinstalled stuff. best regards marcus Friday, May 4, 2007, 9:22:40 PM, you wrote: > On Fri, May 4, 2007 1:09 pm, Antony Dovgal wrote: >> If you don't like PECL or think it's too difficult to use, let's make >> it easy enough for all. > How easy is it for an average user on a shared host that needs X, to > use pecl to get X, without an intervention by the webhost? > I know y'all don't have this issue; But a few zillion PHP developers do. > -- > Some people have a "gift" link here. > Know what I want? > I want you to buy a CD from some indie artist. > http://cdbaby.com/browse/from/lynch > Yeah, I get a buck. So? Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Ilia Alshanetsky wrote: On 4-May-07, at 3:14 PM, Lukas Kahwe Smith wrote: Yes, to me the question is only if we want to give the message that software producers should be able to expect phar to be there on 99% of the systems. Thats the only way that phar has a good chance of really taking off as a php code distribution approach. It sounds like the merits of having phar is would only be apparent after it is included in the core and everyone starts using it because of that. This won't happen simply because most software producers can't rely on extensions that are only available in version X. No, the point is that if we want to push something, we need to add it sooner rather than later, because there will be a delay anyways. Also simply by putting it into core, we make sure that phar gets into the long terms plans of users (which are then more likely to accept the transition pain, because they know its going to be around and maintained). regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
obsolete set of tools (autoconf-2.13, etc.). Having Phar in the main distro will open up a whole new way to distribute PHP applications which would be a great advantage. The current system of distributing a bunch of PHP files has some shortcomings. I'm personally not sure phar is that great way of distributing apps - it's yet another format not supported by standard tools and I don't really see much of an advantage to using it versus just making a package with any of the existing package formats and I see a number of disadvantages - non-standard format, hard to work with packed scripts with available filesystem tools, etc. But that's my opinion and I fully expect some people to hold exactly the opposite opinion. The question is however is phar so important that everybody needs it in the main source? -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Stanislav Malyshev wrote: expect some people to hold exactly the opposite opinion. The question is however is phar so important that everybody needs it in the main source? Yup, that is indeed the question. Like I said I think it is important enough. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Hello Stanislav, - you don't need a tool - well php - but hey you probbaly have that tool - you can run phar archives out of the box - untouched - you can extract phar archives and run them - still untouched - you can provide phar archives that do not require a phar extension To your question "is phar so important that everybody needs it in the main source." I think the above means it should. best regards marcus Friday, May 4, 2007, 9:36:22 PM, you wrote: >> obsolete set of tools (autoconf-2.13, etc.). Having Phar in the main >> distro will open up a whole new way to distribute PHP applications which >> would be a great advantage. The current system of distributing a bunch >> of PHP files has some shortcomings. > I'm personally not sure phar is that great way of distributing apps - > it's yet another format not supported by standard tools and I don't > really see much of an advantage to using it versus just making a package > with any of the existing package formats and I see a number of > disadvantages - non-standard format, hard to work with packed scripts > with available filesystem tools, etc. But that's my opinion and I fully > expect some people to hold exactly the opposite opinion. The question is > however is phar so important that everybody needs it in the main source? > -- > Stanislav Malyshev, Zend Products Engineer > [EMAIL PROTECTED] http://www.zend.com/ Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Starting 5.3
I think phar is a nice idea but honestly haven't had enough bandwidth to check it out in more detail. Has there been some thorough analysis on the performance impact of it and whether this is the optimal recommended way for our users to distribute apps? The idea is actually very interesting but we should be pretty certain we're doing the right thing before we distribute it. We can spend some time looking at it in more detail. Btw, it seems to me that because of the way Apache works for most of our users it actually won't be that useful and just act like a .tar archieve which needs to be extracted. This is unless the user implements some kind of front controller. It would really be nice if we have the 99% common Apache application use-case figured out and docuemnted before we put our PHP dev team weight behind it. Or am I completely missing some magic here? Re: debug info for files. I wouldn't like to see that in non-debug runs. It could be optional at runtime if you want. Andi > -Original Message- > From: Marcus Boerger [mailto:[EMAIL PROTECTED] > Sent: Friday, May 04, 2007 12:44 PM > To: Stas Malyshev > Cc: Edin Kadribasic; internals@lists.php.net > Subject: Re: [PHP-DEV] [RFC] Starting 5.3 > > Hello Stanislav, > > - you don't need a tool - well php - but hey you probbaly > have that tool > - you can run phar archives out of the box - untouched > - you can extract phar archives and run them - still untouched > - you can provide phar archives that do not require a phar extension > > To your question "is phar so important that everybody needs > it in the main source." I think the above means it should. > > best regards > marcus > > Friday, May 4, 2007, 9:36:22 PM, you wrote: > > >> obsolete set of tools (autoconf-2.13, etc.). Having Phar > in the main > >> distro will open up a whole new way to distribute PHP applications > >> which would be a great advantage. The current system of > distributing > >> a bunch of PHP files has some shortcomings. > > > I'm personally not sure phar is that great way of > distributing apps - > > it's yet another format not supported by standard tools and I don't > > really see much of an advantage to using it versus just making a > > package with any of the existing package formats and I see > a number of > > disadvantages - non-standard format, hard to work with > packed scripts > > with available filesystem tools, etc. But that's my opinion and I > > fully expect some people to hold exactly the opposite opinion. The > > question is however is phar so important that everybody > needs it in the main source? > > -- > > Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] > > http://www.zend.com/ > > > > > Best regards, > Marcus > > -- > PHP Internals - PHP Runtime Development Mailing List To > unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Hello Andi, Friday, May 4, 2007, 9:55:23 PM, you wrote: > I think phar is a nice idea but honestly haven't had enough bandwidth to > check it out in more detail. Has there been some thorough analysis on > the performance impact of it and whether this is the optimal recommended > way for our users to distribute apps? The idea is actually very > interesting but we should be pretty certain we're doing the right thing > before we distribute it. We can spend some time looking at it in more > detail. You guys spent a good effort in such analysis in the past. Would be very nice to hear something in that direction from you. > Btw, it seems to me that because of the way Apache works for most of our > users it actually won't be that useful and just act like a .tar archieve > which needs to be extracted. This is unless the user implements some > kind of front controller. It would really be nice if we have the 99% > common Apache application use-case figured out and docuemnted before we > put our PHP dev team weight behind it. Or am I completely missing some > magic here? not at all. It perfectly works for includes. But i have no idea how to use it from a url directly...well you can provide some tricks. But i wouldn't recommend those. > Andi >> -Original Message- >> From: Marcus Boerger [mailto:[EMAIL PROTECTED] >> Sent: Friday, May 04, 2007 12:44 PM >> To: Stas Malyshev >> Cc: Edin Kadribasic; internals@lists.php.net >> Subject: Re: [PHP-DEV] [RFC] Starting 5.3 >> >> Hello Stanislav, >> >> - you don't need a tool - well php - but hey you probbaly >> have that tool >> - you can run phar archives out of the box - untouched >> - you can extract phar archives and run them - still untouched >> - you can provide phar archives that do not require a phar extension >> >> To your question "is phar so important that everybody needs >> it in the main source." I think the above means it should. >> >> best regards >> marcus >> >> Friday, May 4, 2007, 9:36:22 PM, you wrote: >> >> >> obsolete set of tools (autoconf-2.13, etc.). Having Phar >> in the main >> >> distro will open up a whole new way to distribute PHP applications >> >> which would be a great advantage. The current system of >> distributing >> >> a bunch of PHP files has some shortcomings. >> >> > I'm personally not sure phar is that great way of >> distributing apps - >> > it's yet another format not supported by standard tools and I don't >> > really see much of an advantage to using it versus just making a >> > package with any of the existing package formats and I see >> a number of >> > disadvantages - non-standard format, hard to work with >> packed scripts >> > with available filesystem tools, etc. But that's my opinion and I >> > fully expect some people to hold exactly the opposite opinion. The >> > question is however is phar so important that everybody >> needs it in the main source? >> > -- >> > Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] >> > http://www.zend.com/ >> >> >> >> >> Best regards, >> Marcus >> >> -- >> PHP Internals - PHP Runtime Development Mailing List To >> unsubscribe, visit: http://www.php.net/unsub.php >> >> Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
- you don't need a tool - well php - but hey you probbaly have that tool Yes, but they can't open it by any other standard system tool. I.e. you always need PHP - and of specific version - to work with this file. And I don't know how you expect all kinds of proven and widely used tools like mod_rewrite, .htaccess, etc. to work with phar-ed application. - you can run phar archives out of the box - untouched You can't however see files there, edit files, copy files, etc. by any of the thousands of tools made by people to work with files. - you can extract phar archives and run them - still untouched To extract them, you again can use one and only one tool, which might not be available on the system you want to open the archive on. That's all consequences of inventing yet another separate packaging format on top of dozens already in existence. Java at least used existing format... - you can provide phar archives that do not require a phar extension What do you mean, how? And if you can - why don't you always do so? Why do you need phar extension at all? To your question "is phar so important that everybody needs it in the main source." I think the above means it should. Sorry, not clear to me how exactly it means so. There are a lot of extensions that live in PECL and do all kinds of interesting things - why phar is so special? -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Starting 5.3
Don't think we every looked at it in detail. Or maybe I just don't remember. I think the URL thing is one of the biggest question marks. It will not be very useful for our users if they can't deploy the one big phar (similar to Java EE WAR or EAR). It can probably be done with some kind of front controller trick and mod_rewrite. It's something worth checking out but it might cause a big performance hit for our users. Andi > -Original Message- > From: Marcus Boerger [mailto:[EMAIL PROTECTED] > Sent: Friday, May 04, 2007 1:06 PM > To: Andi Gutmans > Cc: Stas Malyshev; Edin Kadribasic; internals@lists.php.net > Subject: Re: [PHP-DEV] [RFC] Starting 5.3 > > Hello Andi, > > Friday, May 4, 2007, 9:55:23 PM, you wrote: > > > I think phar is a nice idea but honestly haven't had enough > bandwidth > > to check it out in more detail. Has there been some > thorough analysis > > on the performance impact of it and whether this is the optimal > > recommended way for our users to distribute apps? The idea > is actually > > very interesting but we should be pretty certain we're > doing the right > > thing before we distribute it. We can spend some time > looking at it in > > more detail. > > You guys spent a good effort in such analysis in the past. > Would be very nice to hear something in that direction from you. > > > Btw, it seems to me that because of the way Apache works > for most of > > our users it actually won't be that useful and just act like a .tar > > archieve which needs to be extracted. This is unless the user > > implements some kind of front controller. It would really > be nice if > > we have the 99% common Apache application use-case figured out and > > docuemnted before we put our PHP dev team weight behind it. Or am I > > completely missing some magic here? > > not at all. It perfectly works for includes. But i have no > idea how to use it from a url directly...well you can provide > some tricks. But i wouldn't recommend those. > > > Andi > > >> -Original Message- > >> From: Marcus Boerger [mailto:[EMAIL PROTECTED] > >> Sent: Friday, May 04, 2007 12:44 PM > >> To: Stas Malyshev > >> Cc: Edin Kadribasic; internals@lists.php.net > >> Subject: Re: [PHP-DEV] [RFC] Starting 5.3 > >> > >> Hello Stanislav, > >> > >> - you don't need a tool - well php - but hey you probbaly > have that > >> tool > >> - you can run phar archives out of the box - untouched > >> - you can extract phar archives and run them - still untouched > >> - you can provide phar archives that do not require a phar > extension > >> > >> To your question "is phar so important that everybody > needs it in the > >> main source." I think the above means it should. > >> > >> best regards > >> marcus > >> > >> Friday, May 4, 2007, 9:36:22 PM, you wrote: > >> > >> >> obsolete set of tools (autoconf-2.13, etc.). Having Phar > >> in the main > >> >> distro will open up a whole new way to distribute PHP > applications > >> >> which would be a great advantage. The current system of > >> distributing > >> >> a bunch of PHP files has some shortcomings. > >> > >> > I'm personally not sure phar is that great way of > >> distributing apps - > >> > it's yet another format not supported by standard tools > and I don't > >> > really see much of an advantage to using it versus just making a > >> > package with any of the existing package formats and I see > >> a number of > >> > disadvantages - non-standard format, hard to work with > >> packed scripts > >> > with available filesystem tools, etc. But that's my > opinion and I > >> > fully expect some people to hold exactly the opposite > opinion. The > >> > question is however is phar so important that everybody > >> needs it in the main source? > >> > -- > >> > Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] > >> > http://www.zend.com/ > >> > >> > >> > >> > >> Best regards, > >> Marcus > >> > >> -- > >> PHP Internals - PHP Runtime Development Mailing List To > unsubscribe, > >> visit: http://www.php.net/unsub.php > >> > >> > > > > Best regards, > Marcus > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Starting 5.3
Btw, I think if phar is a good way of deploying self-contained apps like WAR and EAR then we should think of including this in the default distro. It definitely has value. I just don't think we're quite there yet. Andi > -Original Message- > From: Stanislav Malyshev [mailto:[EMAIL PROTECTED] > Sent: Friday, May 04, 2007 1:07 PM > To: Marcus Boerger > Cc: Edin Kadribasic; internals@lists.php.net > Subject: Re: [PHP-DEV] [RFC] Starting 5.3 > > > - you don't need a tool - well php - but hey you probbaly have that > > tool > > Yes, but they can't open it by any other standard system > tool. I.e. you always need PHP - and of specific version - to > work with this file. And I don't know how you expect all > kinds of proven and widely used tools like mod_rewrite, > .htaccess, etc. to work with phar-ed application. > > > - you can run phar archives out of the box - untouched > > You can't however see files there, edit files, copy files, > etc. by any of the thousands of tools made by people to work > with files. > > > - you can extract phar archives and run them - still untouched > > To extract them, you again can use one and only one tool, > which might not be available on the system you want to open > the archive on. That's all consequences of inventing yet > another separate packaging format on top of dozens already in > existence. Java at least used existing format... > > > - you can provide phar archives that do not require a phar extension > > What do you mean, how? And if you can - why don't you always > do so? Why do you need phar extension at all? > > > To your question "is phar so important that everybody needs > it in the > > main source." I think the above means it should. > > Sorry, not clear to me how exactly it means so. There are a > lot of extensions that live in PECL and do all kinds of > interesting things - why phar is so special? > -- > Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] > http://www.zend.com/ > > -- > PHP Internals - PHP Runtime Development Mailing List To > unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Hello Stanislav, Friday, May 4, 2007, 10:07:13 PM, you wrote: >> - you don't need a tool - well php - but hey you probbaly have that tool > Yes, but they can't open it by any other standard system tool. I.e. you > always need PHP - and of specific version - nope, there ispear/phar - perfectly compatible and runs on any version > to work with this file. And > I don't know how you expect all kinds of proven and widely used tools > like mod_rewrite, .htaccess, etc. to work with phar-ed application. they most likely don't, it is designed for deployment and for running includes directly. >> - you can run phar archives out of the box - untouched > You can't however see files there, edit files, copy files, etc. by any > of the thousands of tools made by people to work with files. If need be, i'll write a windows-commander plugin :-) >> - you can extract phar archives and run them - still untouched > To extract them, you again can use one and only one tool, which might > not be available on the system you want to open the archive on. That's > all consequences of inventing yet another separate packaging format on > top of dozens already in existence. Java at least used existing format... pear install phar - or - pecl install phar - done oh wait the point is that pecl install doesn't work or is in 99% no option >> - you can provide phar archives that do not require a phar extension > What do you mean, how? And if you can - why don't you always do so? Why > do you need phar extension at all? slow? bigger? overhead? >> To your question "is phar so important that everybody needs it in the >> main source." I think the above means it should. > Sorry, not clear to me how exactly it means so. There are a lot of > extensions that live in PECL and do all kinds of interesting things - > why phar is so special? Interesting and not maintained for the most. Sometimes working on one or the other very specific php version only. And often even without documentation. > -- > Stanislav Malyshev, Zend Products Engineer > [EMAIL PROTECTED] http://www.zend.com/ Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Bug? Raw POST data in PHP 5.2.2, take two
I believe this is a bug in PHP 5.2.2. I've tried to report this for PHP
5.2.2RC2 but apparently wasn't making myself clear or wasn't following
the proper procedures ...
Anyway, as I wrote before[1], "raw" POST data isn't making it through in
PHP 5.2.2 which results in XML-RPC communications to fail, at least when
using the PEAR::XML_RPC package.
Consider this little script (send.php):
--- snip ---
http://www.example.com/'; // doesn't matter here
$targetURI = $sourceURI;
$client = new XML_RPC_Client('/receive.php', $_SERVER['HTTP_HOST']);
$client->setDebug(1);
$msg = new XML_RPC_Message('pingback.ping',
array(new XML_RPC_Value($sourceURI, 'string'),
new XML_RPC_Value($targetURI, 'string')));
$response = $client->send($msg, 0, 'http');
?>
--- snip ---
This makes a simple XML-RPC call as used for Pingbacks. For the
receiving end of the communication, let's use this as receive.php:
--- snip ---
--- snip ---
Now when I call up send.php (both located in the web root of a server
running PHP 5.2.2), I get this output:
---GOT---
HTTP/1.1 200 OK
Date: Fri, 04 May 2007 20:07:58 GMT
Server: Apache/1.3.37 (Unix) PHP/5.2.2
X-Powered-By: PHP/5.2.2
Connection: close
Content-Type: text/html
Array
(
[Content-Length] => 282
[Content-Type] => text/xml
[Host] => myhost.example.com
[User-Agent] => PEAR XML_RPC
)
Notice: Undefined index: HTTP_RAW_POST_DATA in /usr/local/
apache/vhost/geeklog/public_html/receive.php on line 5
---END---
So $GLOBALS['HTTP_RAW_POST_DATA'] is not set. The PEAR::XML_RPC package
actually uses $HTTP_RAW_POST_DATA on the receiving end, but that doesn't
appear to be set either. And the always_populate_raw_post_data option in
php.ini doesn't make a difference.
Switching back to PHP 5.2.1 (same machine, same configuration) makes
everything work as expected:
---GOT---
HTTP/1.1 200 OK
Date: Fri, 04 May 2007 20:11:28 GMT
Server: Apache/1.3.37 (Unix) PHP/5.2.1
X-Powered-By: PHP/5.2.1
Connection: close
Content-Type: text/html
Array
(
[Content-Length] => 282
[Content-Type] => text/xml
[Host] => myhost.example.com
[User-Agent] => PEAR XML_RPC
)
pingback.ping
http://www.example.com/
http://www.example.com/
---END---
This is on a Linux box, but I have confirmation (thanks, Mike) of the
same thing happening on Windows.
Can anyone please
1) confirm this or tell me what I'm doing wrong and
2) tell me what else I should have done (other than posting here and
emailing Ilia, as the PHP 5 release manager), in case I ever run into
something similar again.
Thanks.
bye, Dirk
[1]
--
http://www.geeklog.net/
http://geeklog.info/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug? Raw POST data in PHP 5.2.2, take two
Is your always_populate_raw_post_data enabled? Also, have you tried
accessing the data from php://input ?
On 4-May-07, at 4:18 PM, Dirk Haun wrote:
I believe this is a bug in PHP 5.2.2. I've tried to report this for
PHP
5.2.2RC2 but apparently wasn't making myself clear or wasn't following
the proper procedures ...
Anyway, as I wrote before[1], "raw" POST data isn't making it
through in
PHP 5.2.2 which results in XML-RPC communications to fail, at least
when
using the PEAR::XML_RPC package.
Consider this little script (send.php):
--- snip ---
http://www.example.com/'; // doesn't matter here
$targetURI = $sourceURI;
$client = new XML_RPC_Client('/receive.php', $_SERVER['HTTP_HOST']);
$client->setDebug(1);
$msg = new XML_RPC_Message('pingback.ping',
array(new XML_RPC_Value($sourceURI, 'string'),
new XML_RPC_Value($targetURI, 'string')));
$response = $client->send($msg, 0, 'http');
?>
--- snip ---
This makes a simple XML-RPC call as used for Pingbacks. For the
receiving end of the communication, let's use this as receive.php:
--- snip ---
--- snip ---
Now when I call up send.php (both located in the web root of a server
running PHP 5.2.2), I get this output:
---GOT---
HTTP/1.1 200 OK
Date: Fri, 04 May 2007 20:07:58 GMT
Server: Apache/1.3.37 (Unix) PHP/5.2.2
X-Powered-By: PHP/5.2.2
Connection: close
Content-Type: text/html
Array
(
[Content-Length] => 282
[Content-Type] => text/xml
[Host] => myhost.example.com
[User-Agent] => PEAR XML_RPC
)
Notice: Undefined index: HTTP_RAW_POST_DATA in /usr/local/
apache/vhost/geeklog/public_html/receive.php on line 5b>
---END---
So $GLOBALS['HTTP_RAW_POST_DATA'] is not set. The PEAR::XML_RPC
package
actually uses $HTTP_RAW_POST_DATA on the receiving end, but that
doesn't
appear to be set either. And the always_populate_raw_post_data
option in
php.ini doesn't make a difference.
Switching back to PHP 5.2.1 (same machine, same configuration) makes
everything work as expected:
---GOT---
HTTP/1.1 200 OK
Date: Fri, 04 May 2007 20:11:28 GMT
Server: Apache/1.3.37 (Unix) PHP/5.2.1
X-Powered-By: PHP/5.2.1
Connection: close
Content-Type: text/html
Array
(
[Content-Length] => 282
[Content-Type] => text/xml
[Host] => myhost.example.com
[User-Agent] => PEAR XML_RPC
)
pingback.ping
http://www.example.com/
http://www.example.com/
---END---
This is on a Linux box, but I have confirmation (thanks, Mike) of the
same thing happening on Windows.
Can anyone please
1) confirm this or tell me what I'm doing wrong and
2) tell me what else I should have done (other than posting here and
emailing Ilia, as the PHP 5 release manager), in case I ever run into
something similar again.
Thanks.
bye, Dirk
[1]
--
http://www.geeklog.net/
http://geeklog.info/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Ilia Alshanetsky
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug? Raw POST data in PHP 5.2.2, take two
Ilia Alshanetsky wrote: >Is your always_populate_raw_post_data enabled? Yes: ; Always populate the $HTTP_RAW_POST_DATA variable. always_populate_raw_post_data = On As I already said: On or Off doesn't seem to make a difference. >Also, have you tried >accessing the data from php://input ? I have to admit that I wouldn't know how to do that - never used php:// input before. It also wouldn't help with the PEAR::XML_RPC package (which we normally use on the receiving end). bye, Dirk -- http://www.geeklog.net/ http://geeklog.info/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mail() logging for PHP
Hi, Ilia Alshanetsky wrote: I am going to finalize the patch and add it to 5.2.2 in the coming weeks. Ilia There is no trace of such patch in PHP 5.2.2 changelog. Any news on it? Thanks. Mathieu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
