[PHP-DEV] Suggestion on static field inheritance
Hello all,
Maybe I have not found its detailed description on PHP's official manual,
but PHP does allow static field inheritance. However there is a little
difference between dynamic field inheritance and static field inheritance,
as the following codes shows:
name = $name;
}
public $name = 'a';
}
class dynamic_c extends dynamic_a {}
class dynamic_d extends dynamic_a {}
$a = new dynamic_a();
$c = new dynamic_c();
$d = new dynamic_d();
echo $a->name; // a
$c->change('c');
echo $a->name; // a
$d->change('d');
echo $a->name; // a
?>
The result of static inheritance test can be meaningful on some
way(especially on class-based programming perspective), but when considering
the static class as "object" in prototype-based programming(which I doubt is
some people's favourite who comes from prototype-based OOP community), this
result can be confusing. On JavaScript, this example can be:
function extends(parent) {
var T = function () {};
T.prototype = parent;
return new T();
}
var static_a = {
name: 'a',
change: function (name) {
this.name = name;
}
};
var static_c = extends(static_a);
var static_d = extends(static_a);
alert(static_a.name); // a
static_c.change('c');
alert(static_a.name); // a
static_d.change('d');
alert(static_a.name); // a
This looks more meaningful. So my suggestion is, could PHP's static
inheritance rule follow the dynamic inheritance rule ( $this on dynamic, or
prototype delegation on JavaScript) ?
Thanks :-)
--
Best regards,
Jingcheng Zhang
P.R.China
Re: [PHP-DEV] Re: Why does $_REQUEST exist?
Am Freitag, 15. Mai 2009 schrieb Michael Shadle: Hallo, > There's gotta be a time in the natural evolution to "cut the cord" so > to speak - Python just launched 3.0 and dropped backwards > compatibility. Why can't PHP do the same in 6.0? :) (Or 5.3 for all I > care. But it really should align with a major revision #) Splitting PHP in 3 independent parts could help solving the backwards problem. - Library (Functions, Methods) - Virtual Machine (Zend Engine) - Compiler for PHP 5.2, PHP 6, ... Library | VM | P-Code/Bytecode / | \ /| \ 5.25.36.0 ... compiler So a system could contain a compiler for each major PHP version. Sourcecode written for PHP 5.2 will use PHP compiler 5.2, sourcecode for PHP 6.0 will use PHP compiler 6.0, ... No backwards problem for existing code. It's still necessary to update 5.2 code to use it with the PHP 6.0 compiler but the existing code does not prevent to use PHP 6.0 now for new scripts and classes. And this is IMO easier then using (fast) CGI or multiple instances of a webserver to have different versions of PHP on one server. There could also be different major versions of the library. tschuess [|8:) http://www.sven-drieling.de/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Why does $_REQUEST exist?
On Fri, May 15, 2009 at 1:25 PM, Lukas Kahwe Smith wrote: > Confusing new code is totally different from breaking existing code. True but aren't some changes in 6.0 at least (and possibly 5.3) going to require code changes? Or is it still going to be "legacy enough" ? There's gotta be a time in the natural evolution to "cut the cord" so to speak - Python just launched 3.0 and dropped backwards compatibility. Why can't PHP do the same in 6.0? :) (Or 5.3 for all I care. But it really should align with a major revision #) > Just FYI: Not sure which blog you are talking about, but that is Stefan > Esser's blog that is linked above. Sorry, used to most people pushing their own blog links :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3.0RC3
Hi! If tests need fixing and you dont have the time for this, I am sure we will find people that do. I definitely don't have time for doing it, so I'd be happy if somebody else does that thing. -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Why does $_REQUEST exist?
On 15.05.2009, at 19:14, Michael Shadle wrote: On Fri, May 15, 2009 at 1:32 AM, Lukas Kahwe Smith wrote: The more stuff like this we remove, the harder it becomes for people to quickly move to newer, faster and more secure versions of PHP. That causes way more frustration for everyone than a few "ugly" legacy features. If there is a decent technical reason, performance or security, then we need to take a hard look at it. In this case, the thing we should be looking at isn't whether we should remove $_REQUEST but whether we should remove cookie data from it. Many configurations already do that, including all of my own, and there is a strong valid security reason for not including cookies in $_REQUEST. Most people use $_REQUEST to mean GET or POST, not realizing that it could also contain cookies and as such bad guys could potentially do some cookie injection tricks and break naive applications. But since there is going to be a dramatic change here anyway, this is the perfect time to do it. To me adding namespaces is a lot more scary and will lead to a lot of confusing code... Confusing new code is totally different from breaking existing code. Its already fixed in 5.3. There is a new ini option that defines what should go into $_REQUEST. See the following blog post for details: http://www.suspekt.org/2008/10/01/php-53-and-delayed-cross-site-request-forgerieshijacking/ Also a lot of work was put into restructuring the php.ini files we ship with PHP. This is a good step I think; will it be possible to allow it to be empty and have $_REQUEST not exist or even be initialized? Also, you said it yourself in your blog - not caring what is done via GET and POST is bad practice. Why not enforce this in the engine? Just FYI: Not sure which blog you are talking about, but that is Stefan Esser's blog that is linked above. Also, I had thought $_REQUEST had included session data too. At least that is not there. Talk about easy exploitation options then! :) Indeed, that would have been insane. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.2.10
Giovanni Giacobbi wrote: > On Thu, May 14, 2009 at 10:04:36PM +0200, Pierre Joye wrote: >> hi Ilia, >> >> On Thu, May 14, 2009 at 8:54 PM, Andrei Zmievski >> wrote: >>> Jani Taskinen wrote: It's still new stuff. And we need more things in 5.3/6 to make them more interesting to general populus too. ;) >>> Great, so I'll just end up copying almost all of ext/json code into >>> pecl/memcached then. Hooray for loose coupling. >> It is actually not about adding features. If I understand correctly >> what Andrei likes to have, it is only about exposing the JSON API. >> That means no code change (no new feature or whatever else) but only >> adding the right PHP_API related declaration to the right place and >> install the json header. That could actually be very useful with no >> impact on the code (userland or extensions). >> >> I think we should allow this change. >> > > Sorry if I'm not getting this right, but doesn't he have to explicitly > require version >= 5.2.10 in his pecl/memcached extension? It's not like that > with this change his extension is going to work for 5.2.x. Requiring >= > 5.2.10 is such a strict requirement that should be replaced with >= 5.3.0. > You can use call_user_func_ex() internally to call it, it's nicer to use the C API though. Though this is the wrong place to ask. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.2.10
On Thu, May 14, 2009 at 10:04:36PM +0200, Pierre Joye wrote: > hi Ilia, > > On Thu, May 14, 2009 at 8:54 PM, Andrei Zmievski > wrote: > > Jani Taskinen wrote: > >> > >> It's still new stuff. And we need more things in 5.3/6 to make them more > >> interesting to general populus too. ;) > > > > Great, so I'll just end up copying almost all of ext/json code into > > pecl/memcached then. Hooray for loose coupling. > > It is actually not about adding features. If I understand correctly > what Andrei likes to have, it is only about exposing the JSON API. > That means no code change (no new feature or whatever else) but only > adding the right PHP_API related declaration to the right place and > install the json header. That could actually be very useful with no > impact on the code (userland or extensions). > > I think we should allow this change. > Sorry if I'm not getting this right, but doesn't he have to explicitly require version >= 5.2.10 in his pecl/memcached extension? It's not like that with this change his extension is going to work for 5.2.x. Requiring >= 5.2.10 is such a strict requirement that should be replaced with >= 5.3.0. -- Giovanni Giacobbi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] extending ignore_errors inside http_fopen_wrappers.c
See also: http://bugs.php.net/38802 Arnaud Le Blanc kirjoitti: On Fri, 2009-05-15 at 11:49 -0400, Ilia Alshanetsky wrote: the patch looks good. Same here. Lukas, Johannes, can this be commited to 5.3 ? Regards, Arnaud Ilia Alshanetsky On 15-May-09, at 11:36 AM, Tjerk Anne Meesters wrote: Hi Arnaud, Thanks for the tip, please find patch attached. Best, Tjerk On Fri, May 15, 2009 at 10:58 PM, Arnaud Le Blanc wrote: Hi, On Fri, 2009-05-15 at 22:16 +0800, Tjerk Anne Meesters wrote: Hi, I've been extending the pecl/oauth code to work with php stream wrappers in cases whereby curl is not enabled, but I've hit a snag. The documentation states that enabling the "ignore_errors" flag will fetch the content even on failure status codes. At the same time, setting "max_redirects" to <= 1 indicates that no redirects will be followed. It does not state that setting "max_redirects" <= 1 would actually trigger an error, though in the code it returns (php_stream *)NULL making it impossible to even get the headers out of the wrapperdata hash unless STREAM_ONLY_GET_HEADERS is used. So, either setting "max_redirects" <= 1 should not throw NULL back into the caller code or "ignore_error" behaviour should be extended to prevent that from happening. My attached patch favours to fix the latter, since the "ignore_errors" is a relatively new flag. Hope it will be accepted for the 5.3 release. max_redirects's purpose is to avoid infinite loops, etc. Stream functions are expected to return an error in case the limit is exceeded. If they do not, scripts will get an empty body without noticing the error (changing this may break existing scripts). ignore_errors is a new flag, it forces scripts to check HTTP status code (so that scripts will notice non-200 ones) and changing it to ignore redirects when max_redirects is exceeded seems to be a good solution. (not sure whether attachments will be allowed ... give me a ping if it doesn't make it through) The list accepts only text/plain attachments (try renaming your patch to .txt). Regards, Arnaud -- -- Tjerk -- 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] Re: Why does $_REQUEST exist?
On Fri, May 15, 2009 at 1:32 AM, Lukas Kahwe Smith wrote: >> The more stuff like this we remove, the harder it becomes for people to >> quickly move to newer, faster and more secure versions of PHP. That >> causes way more frustration for everyone than a few "ugly" legacy >> features. If there is a decent technical reason, performance or >> security, then we need to take a hard look at it. In this case, the >> thing we should be looking at isn't whether we should remove $_REQUEST >> but whether we should remove cookie data from it. Many configurations >> already do that, including all of my own, and there is a strong valid >> security reason for not including cookies in $_REQUEST. Most people use >> $_REQUEST to mean GET or POST, not realizing that it could also contain >> cookies and as such bad guys could potentially do some cookie injection >> tricks and break naive applications. But since there is going to be a dramatic change here anyway, this is the perfect time to do it. To me adding namespaces is a lot more scary and will lead to a lot of confusing code... P.S. It looks like you'll be speaking at OSBridge in Portland in a month or so. If I attend I look forward to meeting you and thanking you for PHP :) > Its already fixed in 5.3. There is a new ini option that defines what should > go into $_REQUEST. See the following blog post for details: > http://www.suspekt.org/2008/10/01/php-53-and-delayed-cross-site-request-forgerieshijacking/ > > Also a lot of work was put into restructuring the php.ini files we ship with > PHP. This is a good step I think; will it be possible to allow it to be empty and have $_REQUEST not exist or even be initialized? Also, you said it yourself in your blog - not caring what is done via GET and POST is bad practice. Why not enforce this in the engine? It makes PHP look insecure when apps have security issues because of poor coding. It's not because PHP itself had a flaw, but to a lot of people, they see "PHPNuke" or know that postnuke runs under PHP, or phpbb, etc - the language -can- enforce better techniques, especially since 5.3 and 6.0 will require some changes in code anyway; this one is a pretty simple change too - Someone could make a function like import_request_variables() but allow it to re-create $_REQUEST and tell people to put it at the top of their scripts or a central include file if they're too lazy to fix their code to be more secure. I for one would love to see this be enforced at the engine level, so that packages I wind up having to use like Wordpress/etc. have been forced to change their logic (hopefully) to go back to $_GET, $_POST etc. Also, I had thought $_REQUEST had included session data too. At least that is not there. Talk about easy exploitation options then! :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] extending ignore_errors inside http_fopen_wrappers.c
On Fri, 2009-05-15 at 11:49 -0400, Ilia Alshanetsky wrote: > the patch looks good. Same here. Lukas, Johannes, can this be commited to 5.3 ? Regards, Arnaud > > > Ilia Alshanetsky > > > > > On 15-May-09, at 11:36 AM, Tjerk Anne Meesters wrote: > > > Hi Arnaud, > > > > Thanks for the tip, please find patch attached. > > > > > > Best, > > Tjerk > > > > On Fri, May 15, 2009 at 10:58 PM, Arnaud Le Blanc > > wrote: > >> Hi, > >> > >> On Fri, 2009-05-15 at 22:16 +0800, Tjerk Anne Meesters wrote: > >>> Hi, > >>> > >>> I've been extending the pecl/oauth code to work with php stream > >>> wrappers in cases whereby curl is not enabled, but I've hit a snag. > >>> > >>> The documentation states that enabling the "ignore_errors" flag will > >>> fetch the content even on failure status codes. At the same time, > >>> setting "max_redirects" to <= 1 indicates that no redirects will be > >>> followed. > >>> > >>> It does not state that setting "max_redirects" <= 1 would actually > >>> trigger an error, though in the code it returns (php_stream *)NULL > >>> making it impossible to even get the headers out of the wrapperdata > >>> hash unless STREAM_ONLY_GET_HEADERS is used. > >>> > >>> So, either setting "max_redirects" <= 1 should not throw NULL back > >>> into the caller code or "ignore_error" behaviour should be > >>> extended to > >>> prevent that from happening. > >>> > >>> My attached patch favours to fix the latter, since the > >>> "ignore_errors" > >>> is a relatively new flag. Hope it will be accepted for the 5.3 > >>> release. > >> > >> max_redirects's purpose is to avoid infinite loops, etc. Stream > >> functions are expected to return an error in case the limit is > >> exceeded. > >> If they do not, scripts will get an empty body without noticing the > >> error (changing this may break existing scripts). > >> > >> ignore_errors is a new flag, it forces scripts to check HTTP status > >> code > >> (so that scripts will notice non-200 ones) and changing it to ignore > >> redirects when max_redirects is exceeded seems to be a good solution. > >> > >>> > >>> (not sure whether attachments will be allowed ... give me a ping > >>> if it > >>> doesn't make it through) > >> > >> The list accepts only text/plain attachments (try renaming your patch > >> to .txt). > >> > >> > >> Regards, > >> > >> Arnaud > >> > >> > >> > > > > > > > > -- > > -- > > Tjerk > > -- > > 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] First test submission and comment correction
Simon Westcott wrote:
Hi,
I've just started to explore PHP's tests, reading through the docs on
qa.php.net, the wiki and a few blogs. Having gotten to a position where
I can run the tests and produce coverage reports I have my first
(simple) submission. It covers an edge case for array_multisort when an
empty array is provided.
Hi Simon,
Welcome!
I've merged these for you. I added an exit() block to the test. See
the "Last bit" section in http://qa.php.net/write-test.php
Let us know if you have any questions or if there's anyway we can help
you. What parts of PHP are you looking at now?
Chris
Test:
$ cat ext/standard/tests/array/array_multisort_variation11.phpt
--TEST--
Test array_multisort() function : usage variation - testing with empty
array
--FILE--
/* Prototype : bool array_multisort(array ar1 [, SORT_ASC|SORT_DESC [,
SORT_REGULAR|SORT_NUMERIC|SORT_STRING]] [, array ar2 [,
SORT_ASC|SORT_DESC [, SORT_REGULAR|SORT_NUMERIC|SORT_STRING]], ...])
* Description: Sort multiple arrays at once similar to how ORDER BY
clause works in SQL
* Source code: ext/standard/array.c
* Alias to functions:
*/
echo "*** Testing array_multisort() : Testing with empty array ***\n";
var_dump(array_multisort(array()));
?>
===DONE===
--EXPECTF--
*** Testing array_multisort() : Testing with empty array ***
bool(true)
===DONE===
Whilst producing this simple test I spotted a mistake in a related
comment which appears to originate from bug 24897. A patch against
PHP-5.3 follows,
Index: ext/standard/array.c
===
RCS file: /repository/php-src/ext/standard/array.c,v
retrieving revision 1.308.2.21.2.37.2.53
diff -u -r1.308.2.21.2.37.2.53 array.c
--- ext/standard/array.c13 Feb 2009 22:34:15 -
1.308.2.21.2.37.2.53
+++ ext/standard/array.c5 May 2009 22:56:53 -
@@ -3789,7 +3789,7 @@
}
}
- /* If all arrays are empty or have only one entry, we don't need
to do anything. */
+ /* If all arrays are empty we don't need to do anything. */
if (array_size < 1) {
for (k = 0; k < MULTISORT_LAST; k++) {
efree(ARRAYG(multisort_flags)[k]);
I appreciate this a trivial stuff, but any constructive feedback is
welcome.
Regards,
Simon Westcott
--
Email: christopher.jo...@oracle.com
Twitter: http://twitter.com/ghrd
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] extending ignore_errors inside http_fopen_wrappers.c
the patch looks good. Ilia Alshanetsky On 15-May-09, at 11:36 AM, Tjerk Anne Meesters wrote: Hi Arnaud, Thanks for the tip, please find patch attached. Best, Tjerk On Fri, May 15, 2009 at 10:58 PM, Arnaud Le Blanc wrote: Hi, On Fri, 2009-05-15 at 22:16 +0800, Tjerk Anne Meesters wrote: Hi, I've been extending the pecl/oauth code to work with php stream wrappers in cases whereby curl is not enabled, but I've hit a snag. The documentation states that enabling the "ignore_errors" flag will fetch the content even on failure status codes. At the same time, setting "max_redirects" to <= 1 indicates that no redirects will be followed. It does not state that setting "max_redirects" <= 1 would actually trigger an error, though in the code it returns (php_stream *)NULL making it impossible to even get the headers out of the wrapperdata hash unless STREAM_ONLY_GET_HEADERS is used. So, either setting "max_redirects" <= 1 should not throw NULL back into the caller code or "ignore_error" behaviour should be extended to prevent that from happening. My attached patch favours to fix the latter, since the "ignore_errors" is a relatively new flag. Hope it will be accepted for the 5.3 release. max_redirects's purpose is to avoid infinite loops, etc. Stream functions are expected to return an error in case the limit is exceeded. If they do not, scripts will get an empty body without noticing the error (changing this may break existing scripts). ignore_errors is a new flag, it forces scripts to check HTTP status code (so that scripts will notice non-200 ones) and changing it to ignore redirects when max_redirects is exceeded seems to be a good solution. (not sure whether attachments will be allowed ... give me a ping if it doesn't make it through) The list accepts only text/plain attachments (try renaming your patch to .txt). Regards, Arnaud -- -- Tjerk -- 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] extending ignore_errors inside http_fopen_wrappers.c
Hi Arnaud,
Thanks for the tip, please find patch attached.
Best,
Tjerk
On Fri, May 15, 2009 at 10:58 PM, Arnaud Le Blanc wrote:
> Hi,
>
> On Fri, 2009-05-15 at 22:16 +0800, Tjerk Anne Meesters wrote:
>> Hi,
>>
>> I've been extending the pecl/oauth code to work with php stream
>> wrappers in cases whereby curl is not enabled, but I've hit a snag.
>>
>> The documentation states that enabling the "ignore_errors" flag will
>> fetch the content even on failure status codes. At the same time,
>> setting "max_redirects" to <= 1 indicates that no redirects will be
>> followed.
>>
>> It does not state that setting "max_redirects" <= 1 would actually
>> trigger an error, though in the code it returns (php_stream *)NULL
>> making it impossible to even get the headers out of the wrapperdata
>> hash unless STREAM_ONLY_GET_HEADERS is used.
>>
>> So, either setting "max_redirects" <= 1 should not throw NULL back
>> into the caller code or "ignore_error" behaviour should be extended to
>> prevent that from happening.
>>
>> My attached patch favours to fix the latter, since the "ignore_errors"
>> is a relatively new flag. Hope it will be accepted for the 5.3
>> release.
>
> max_redirects's purpose is to avoid infinite loops, etc. Stream
> functions are expected to return an error in case the limit is exceeded.
> If they do not, scripts will get an empty body without noticing the
> error (changing this may break existing scripts).
>
> ignore_errors is a new flag, it forces scripts to check HTTP status code
> (so that scripts will notice non-200 ones) and changing it to ignore
> redirects when max_redirects is exceeded seems to be a good solution.
>
>>
>> (not sure whether attachments will be allowed ... give me a ping if it
>> doesn't make it through)
>
> The list accepts only text/plain attachments (try renaming your patch
> to .txt).
>
>
> Regards,
>
> Arnaud
>
>
>
--
--
Tjerk
Index: http_fopen_wrapper.c
===
RCS file: /repository/php-src/ext/standard/http_fopen_wrapper.c,v
retrieving revision 1.99.2.12.2.9.2.16
diff -u -r1.99.2.12.2.9.2.16 http_fopen_wrapper.c
--- http_fopen_wrapper.c14 May 2009 13:36:56 -
1.99.2.12.2.9.2.16
+++ http_fopen_wrapper.c15 May 2009 13:31:18 -
@@ -104,7 +104,7 @@
size_t chunk_size = 0, file_size = 0;
int eol_detect = 0;
char *transport_string, *errstr = NULL;
- int transport_len, have_header = 0, request_fulluri = 0;
+ int transport_len, have_header = 0, request_fulluri = 0, ignore_errors
= 0;
char *protocol_version = NULL;
int protocol_version_len = 3; /* Default: "1.0" */
struct timeval timeout;
@@ -557,9 +557,11 @@
} else {
response_code = 0;
}
+ if (context &&
SUCCESS==php_stream_context_get_option(context, "http", "ignore_errors",
&tmpzval)) {
+ ignore_errors = zend_is_true(*tmpzval);
+ }
/* when we request only the header, don't fail even on
error codes */
- if ((options & STREAM_ONLY_GET_HEADERS) ||
- (context &&
php_stream_context_get_option(context, "http", "ignore_errors", &tmpzval) ==
SUCCESS && zend_is_true(*tmpzval)) ) {
+ if ((options & STREAM_ONLY_GET_HEADERS) ||
ignore_errors) {
reqok = 1;
}
/* all status codes in the 2xx range are defined by the
specification as successful;
@@ -656,7 +658,7 @@
}
if (!reqok || location[0] != '\0') {
- if (options & STREAM_ONLY_GET_HEADERS && redirect_max <= 1) {
+ if (((options & STREAM_ONLY_GET_HEADERS) || ignore_errors) &&
redirect_max <= 1) {
goto out;
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] extending ignore_errors inside http_fopen_wrappers.c
Hi Arnaud,
Thanks for the tip, please find patch attached.
Best,
Tjerk
On Fri, May 15, 2009 at 10:58 PM, Arnaud Le Blanc wrote:
> Hi,
>
> On Fri, 2009-05-15 at 22:16 +0800, Tjerk Anne Meesters wrote:
>> Hi,
>>
>> I've been extending the pecl/oauth code to work with php stream
>> wrappers in cases whereby curl is not enabled, but I've hit a snag.
>>
>> The documentation states that enabling the "ignore_errors" flag will
>> fetch the content even on failure status codes. At the same time,
>> setting "max_redirects" to <= 1 indicates that no redirects will be
>> followed.
>>
>> It does not state that setting "max_redirects" <= 1 would actually
>> trigger an error, though in the code it returns (php_stream *)NULL
>> making it impossible to even get the headers out of the wrapperdata
>> hash unless STREAM_ONLY_GET_HEADERS is used.
>>
>> So, either setting "max_redirects" <= 1 should not throw NULL back
>> into the caller code or "ignore_error" behaviour should be extended to
>> prevent that from happening.
>>
>> My attached patch favours to fix the latter, since the "ignore_errors"
>> is a relatively new flag. Hope it will be accepted for the 5.3
>> release.
>
> max_redirects's purpose is to avoid infinite loops, etc. Stream
> functions are expected to return an error in case the limit is exceeded.
> If they do not, scripts will get an empty body without noticing the
> error (changing this may break existing scripts).
>
> ignore_errors is a new flag, it forces scripts to check HTTP status code
> (so that scripts will notice non-200 ones) and changing it to ignore
> redirects when max_redirects is exceeded seems to be a good solution.
>
>>
>> (not sure whether attachments will be allowed ... give me a ping if it
>> doesn't make it through)
>
> The list accepts only text/plain attachments (try renaming your patch
> to .txt).
>
>
> Regards,
>
> Arnaud
>
>
>
--
--
Tjerk
Index: http_fopen_wrapper.c
===
RCS file: /repository/php-src/ext/standard/http_fopen_wrapper.c,v
retrieving revision 1.99.2.12.2.9.2.16
diff -u -r1.99.2.12.2.9.2.16 http_fopen_wrapper.c
--- http_fopen_wrapper.c14 May 2009 13:36:56 -
1.99.2.12.2.9.2.16
+++ http_fopen_wrapper.c15 May 2009 13:31:18 -
@@ -104,7 +104,7 @@
size_t chunk_size = 0, file_size = 0;
int eol_detect = 0;
char *transport_string, *errstr = NULL;
- int transport_len, have_header = 0, request_fulluri = 0;
+ int transport_len, have_header = 0, request_fulluri = 0, ignore_errors
= 0;
char *protocol_version = NULL;
int protocol_version_len = 3; /* Default: "1.0" */
struct timeval timeout;
@@ -557,9 +557,11 @@
} else {
response_code = 0;
}
+ if (context &&
SUCCESS==php_stream_context_get_option(context, "http", "ignore_errors",
&tmpzval)) {
+ ignore_errors = zend_is_true(*tmpzval);
+ }
/* when we request only the header, don't fail even on
error codes */
- if ((options & STREAM_ONLY_GET_HEADERS) ||
- (context &&
php_stream_context_get_option(context, "http", "ignore_errors", &tmpzval) ==
SUCCESS && zend_is_true(*tmpzval)) ) {
+ if ((options & STREAM_ONLY_GET_HEADERS) ||
ignore_errors) {
reqok = 1;
}
/* all status codes in the 2xx range are defined by the
specification as successful;
@@ -656,7 +658,7 @@
}
if (!reqok || location[0] != '\0') {
- if (options & STREAM_ONLY_GET_HEADERS && redirect_max <= 1) {
+ if (((options & STREAM_ONLY_GET_HEADERS) || ignore_errors) &&
redirect_max <= 1) {
goto out;
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] extending ignore_errors inside http_fopen_wrappers.c
Hi, On Fri, 2009-05-15 at 22:16 +0800, Tjerk Anne Meesters wrote: > Hi, > > I've been extending the pecl/oauth code to work with php stream > wrappers in cases whereby curl is not enabled, but I've hit a snag. > > The documentation states that enabling the "ignore_errors" flag will > fetch the content even on failure status codes. At the same time, > setting "max_redirects" to <= 1 indicates that no redirects will be > followed. > > It does not state that setting "max_redirects" <= 1 would actually > trigger an error, though in the code it returns (php_stream *)NULL > making it impossible to even get the headers out of the wrapperdata > hash unless STREAM_ONLY_GET_HEADERS is used. > > So, either setting "max_redirects" <= 1 should not throw NULL back > into the caller code or "ignore_error" behaviour should be extended to > prevent that from happening. > > My attached patch favours to fix the latter, since the "ignore_errors" > is a relatively new flag. Hope it will be accepted for the 5.3 > release. max_redirects's purpose is to avoid infinite loops, etc. Stream functions are expected to return an error in case the limit is exceeded. If they do not, scripts will get an empty body without noticing the error (changing this may break existing scripts). ignore_errors is a new flag, it forces scripts to check HTTP status code (so that scripts will notice non-200 ones) and changing it to ignore redirects when max_redirects is exceeded seems to be a good solution. > > (not sure whether attachments will be allowed ... give me a ping if it > doesn't make it through) The list accepts only text/plain attachments (try renaming your patch to .txt). Regards, Arnaud -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] extending ignore_errors inside http_fopen_wrappers.c
Hi, I've been extending the pecl/oauth code to work with php stream wrappers in cases whereby curl is not enabled, but I've hit a snag. The documentation states that enabling the "ignore_errors" flag will fetch the content even on failure status codes. At the same time, setting "max_redirects" to <= 1 indicates that no redirects will be followed. It does not state that setting "max_redirects" <= 1 would actually trigger an error, though in the code it returns (php_stream *)NULL making it impossible to even get the headers out of the wrapperdata hash unless STREAM_ONLY_GET_HEADERS is used. So, either setting "max_redirects" <= 1 should not throw NULL back into the caller code or "ignore_error" behaviour should be extended to prevent that from happening. My attached patch favours to fix the latter, since the "ignore_errors" is a relatively new flag. Hope it will be accepted for the 5.3 release. (not sure whether attachments will be allowed ... give me a ping if it doesn't make it through) Best, Tjerk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Segfault while looping through hash table
On Fri, May 15, 2009 at 12:13 AM, Moriyoshi Koizumi wrote:
> On Fri, May 15, 2009 at 12:31 PM, Farley Knight
> wrote:
>
>> zend_hash_internal_pointer_reset(Z_ARRVAL(zhash));
>>
>> printf("This hash table has %d entries\n",
>> zend_hash_num_elements(Z_ARRVAL(zhash)));
>>
>> int current = 0;
>>
>> while (zend_hash_get_current_data(Z_ARRVAL(zhash), (void**)&value)
>> == SUCCESS) {
>> current++;
>> printf("Currently on entry %d\n", current);
>> if (zend_hash_move_forward(Z_ARRVAL(zhash)) == SUCCESS)
>> printf("Done moving hash forward. Result was successful\n");
>> else
>> printf("Done moving hash forward. Result was a failure\n");
>> }
>>
>
> Does the problem persist if replacing the hashtable functions by the
> _ex counterparts: zend_internal_pointer_reset_ex(),
> zend_hash_get_current_data_ex() and zend_move_forward_ex()? These are
> always recommended (I believe) because the internal HashPosition value
> associated to a hashtable is also used in the user script.
>
> Regards,
> Moriyoshi
>
Actually I believe I did, but if they are recommended, I suppose I
will use them instead. Thanks for pointing that out.
BTW I did provide a link to the rest of the code, but I realize what I
posted above might not be enough to understand where the bug lies.
Should I bother posting a larger portion?
Thanks,
- Farley
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_2) / NEWS configure.in /main php_version.h
Lukas Kahwe Smith kirjoitti: On 14.05.2009, at 20:56, Ilia Alshanetsky wrote: I think Moriyoshi has a point here there are several reports by people who are affected by this, I think it makes sense to leave the introduced functionality as is in 5.3/6, but for PHP 5.2 it probably should be rolled back. I talked to Johannes and he agree's with me that this changes to sorting should not happen in 5.x, so we would also like to see this reverted in 5.3 if it gets reverted in 5.2. Just do it already. Commits talk. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Segfault while looping through hash table
On Fri, May 15, 2009 at 4:03 AM, Antony Dovgal wrote:
> On 15.05.2009 07:31, Farley Knight wrote:
>> while (zend_hash_get_current_data(Z_ARRVAL(zhash), (void**)&value)
>> == SUCCESS) {
>> current++;
>> printf("Currently on entry %d\n", current);
>> if (zend_hash_move_forward(Z_ARRVAL(zhash)) == SUCCESS)
>> printf("Done moving hash forward. Result was successful\n");
>> else
>> printf("Done moving hash forward. Result was a failure\n");
>> }
>
> What's the point of this if() ?
> You continue reading the values even if move_forward() fails (i.e. the end is
> reached).
I threw that in for debugging purposes.. So it's completely useless otherwise :)
>
> --
> Wbr,
> Antony Dovgal
>
- Farley
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] How to contribute for PHP Internals
Yes, why not :) By get involved section, i seek a guideline for contribute for each different points. * Internal development * References * TSRM * Zend Engine API * ... * Coding standard * Get Started * Features * Bugs * motivate ? go to seek a bug now ! * ok, no panic, explain and purpose a patch * ... * Pecl development * How to (ok ...Sara Golemon's book) * What php need ? * QA * Documentation Because php is a very big project and it is dificulte to say: "No problem Rasmus..., you can take a nap, i will fix this bug." ;) for example i like it : http://live.gnome.org/JoinGnome -- ~/sahid http://sahid.funraill.org On Thu, May 14, 2009 at 8:03 PM, Christopher Jones wrote: > > > David Coallier wrote: >> >> 2009/5/14 Sahid Ferdjaoui : >>> >>> Hello Internals, >>> >>> I want to contribute for PHP Internal, >>> but i don't know how to do it. >>> >>> I am ready to give approximately 6 to 12 hours per week for PHP. >>> >>> i have checked a wiki, >>> but i don't see a "get involved" section and i do not know how to start >>> :) >>> >> >> The best way to get started is to check http://php.net/anoncvs make a >> checkout of HEAD (php6) and then go to http://bugs.php.net start >> making patches and attach them to bug reports. >> >> From there you will gain developers trust (People will be tired of >> committing all your patches) and at some point you'll be granted with >> an account :) >> >> Good luck and welcome :) >> > > Yes, welcome! > > Perhaps you could create a "get involved" wiki section based on what you > find out about getting involved? > > Chris > > -- > Email: christopher.jo...@oracle.com > Twitter: http://twitter.com/ghrd > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.2.10
Sorry Hannes - forgot to change To address! Hannes Magnusson wrote: On Thu, May 14, 2009 at 21:25, Lester Caine wrote: Hannes Magnusson wrote: On Thu, May 14, 2009 at 18:45, Lester Caine wrote: Since 5.3 DOES require some work to port legacy applications over Do you have a quick list of things that is required so we can document them, or maybe even fix? Several hundred warnings that are not present currently? Please be more precise. I would like to be, but having downloaded RC2 clean and had a look we still have the major blocker of not having php_interbase.dll in the windows build - so I'm unable to run any of my test stuff ... I don't currently have a Linux box spare to try on that :( -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_2) / NEWS configure.in /main php_version.h
On 14.05.2009, at 20:56, Ilia Alshanetsky wrote: I think Moriyoshi has a point here there are several reports by people who are affected by this, I think it makes sense to leave the introduced functionality as is in 5.3/6, but for PHP 5.2 it probably should be rolled back. I talked to Johannes and he agree's with me that this changes to sorting should not happen in 5.x, so we would also like to see this reverted in 5.3 if it gets reverted in 5.2. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Why does $_REQUEST exist?
On Fri, May 15, 2009 at 10:32, Lukas Kahwe Smith wrote: > > On 15.05.2009, at 10:22, Rasmus Lerdorf wrote: > >> Michael Shadle wrote: >>> >>> On Thu, May 14, 2009 at 3:03 PM, Nathan Rixham wrote: >>> bc? all the reasoning in the world won't justify it to 1 million businesses running php 4 code which is reliant on $_REQUEST behind the scenes. although it would generate a tonne of freelance work :p >>> >>> that code has to change for 5.3 or 6.0 anyway. >>> >>> now is the time to yank out some of the legacy crap. we don't want PHP >>> to be like windows, do we? >> >> The more stuff like this we remove, the harder it becomes for people to >> quickly move to newer, faster and more secure versions of PHP. That >> causes way more frustration for everyone than a few "ugly" legacy >> features. If there is a decent technical reason, performance or >> security, then we need to take a hard look at it. In this case, the >> thing we should be looking at isn't whether we should remove $_REQUEST >> but whether we should remove cookie data from it. Many configurations >> already do that, including all of my own, and there is a strong valid >> security reason for not including cookies in $_REQUEST. Most people use >> $_REQUEST to mean GET or POST, not realizing that it could also contain >> cookies and as such bad guys could potentially do some cookie injection >> tricks and break naive applications. > > > Its already fixed in 5.3. There is a new ini option that defines what should > go into $_REQUEST. See the following blog post for details: And simplified version in the docs http://php.net/request_order -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] README.UPDATE_5_3
Lukas Kahwe Smith wrote: > > On 15.05.2009, at 10:30, Rasmus Lerdorf wrote: > >> In the 5.2 release we have a very nice README.UPDATE_5_2 file that >> explains the changes in 5.2. Could we get a volunteer to do the same >> for 5.3 now that we are close to getting 5.3 out the door? >> >> I guess I could do it, but I am hoping someone already has most of it >> done and just hasn't committed it yet. > > > Actually we already have something thx to Steph: > http://cvs.php.net/viewvc.cgi/php-src/UPGRADING?view=markup&pathrev=PHP_5_3 > > It probably needs some updating and tweaking. Philipp volunteered to > take a look, since I did not hear from Steph in a while and when I last > inquired about this guide a few days ago. Ah, new filename. Let's delete README.UPDATE_5.2 from the 5_3 branch then and make sure we put in references to this new UPGRADING file in the release text. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Why does $_REQUEST exist?
Lukas Kahwe Smith wrote: > > On 15.05.2009, at 10:22, Rasmus Lerdorf wrote: > >> Michael Shadle wrote: >>> On Thu, May 14, 2009 at 3:03 PM, Nathan Rixham >>> wrote: >>> bc? all the reasoning in the world won't justify it to 1 million businesses running php 4 code which is reliant on $_REQUEST behind the scenes. although it would generate a tonne of freelance work :p >>> >>> that code has to change for 5.3 or 6.0 anyway. >>> >>> now is the time to yank out some of the legacy crap. we don't want PHP >>> to be like windows, do we? >> >> The more stuff like this we remove, the harder it becomes for people to >> quickly move to newer, faster and more secure versions of PHP. That >> causes way more frustration for everyone than a few "ugly" legacy >> features. If there is a decent technical reason, performance or >> security, then we need to take a hard look at it. In this case, the >> thing we should be looking at isn't whether we should remove $_REQUEST >> but whether we should remove cookie data from it. Many configurations >> already do that, including all of my own, and there is a strong valid >> security reason for not including cookies in $_REQUEST. Most people use >> $_REQUEST to mean GET or POST, not realizing that it could also contain >> cookies and as such bad guys could potentially do some cookie injection >> tricks and break naive applications. > > > Its already fixed in 5.3. There is a new ini option that defines what > should go into $_REQUEST. See the following blog post for details: > http://www.suspekt.org/2008/10/01/php-53-and-delayed-cross-site-request-forgerieshijacking/ > > > Also a lot of work was put into restructuring the php.ini files we ship > with PHP. Right, I obviously know that, I should have explained better. What I meant by removing cookie data from $_REQUEST was to never allow it at all. Right now you have to set request_order to "GP" in order to not get it. If, like most people, you upgrade and use the same php.ini file as before, then we default back to variables_order which has always included cookie data by default. So, as much as I appreciate the work that has gone into the new recommended php.ini settings, we all know that most people completely ignore our .ini suggestions and go with whatever their distro chooses or whatever they have had in there since their PHP4 days. My prediction is that the bulk of people after upgrading to 5.3 will still have cookies in their $_REQUEST. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] README.UPDATE_5_3
On 15.05.2009, at 10:30, Rasmus Lerdorf wrote: In the 5.2 release we have a very nice README.UPDATE_5_2 file that explains the changes in 5.2. Could we get a volunteer to do the same for 5.3 now that we are close to getting 5.3 out the door? I guess I could do it, but I am hoping someone already has most of it done and just hasn't committed it yet. Actually we already have something thx to Steph: http://cvs.php.net/viewvc.cgi/php-src/UPGRADING?view=markup&pathrev=PHP_5_3 It probably needs some updating and tweaking. Philipp volunteered to take a look, since I did not hear from Steph in a while and when I last inquired about this guide a few days ago. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Why does $_REQUEST exist?
On 15.05.2009, at 10:22, Rasmus Lerdorf wrote: Michael Shadle wrote: On Thu, May 14, 2009 at 3:03 PM, Nathan Rixham wrote: bc? all the reasoning in the world won't justify it to 1 million businesses running php 4 code which is reliant on $_REQUEST behind the scenes. although it would generate a tonne of freelance work :p that code has to change for 5.3 or 6.0 anyway. now is the time to yank out some of the legacy crap. we don't want PHP to be like windows, do we? The more stuff like this we remove, the harder it becomes for people to quickly move to newer, faster and more secure versions of PHP. That causes way more frustration for everyone than a few "ugly" legacy features. If there is a decent technical reason, performance or security, then we need to take a hard look at it. In this case, the thing we should be looking at isn't whether we should remove $_REQUEST but whether we should remove cookie data from it. Many configurations already do that, including all of my own, and there is a strong valid security reason for not including cookies in $_REQUEST. Most people use $_REQUEST to mean GET or POST, not realizing that it could also contain cookies and as such bad guys could potentially do some cookie injection tricks and break naive applications. Its already fixed in 5.3. There is a new ini option that defines what should go into $_REQUEST. See the following blog post for details: http://www.suspekt.org/2008/10/01/php-53-and-delayed-cross-site-request-forgerieshijacking/ Also a lot of work was put into restructuring the php.ini files we ship with PHP. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] README.UPDATE_5_3
In the 5.2 release we have a very nice README.UPDATE_5_2 file that explains the changes in 5.2. Could we get a volunteer to do the same for 5.3 now that we are close to getting 5.3 out the door? I guess I could do it, but I am hoping someone already has most of it done and just hasn't committed it yet. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Why does $_REQUEST exist?
Michael Shadle wrote: > On Thu, May 14, 2009 at 3:03 PM, Nathan Rixham wrote: > >> bc? all the reasoning in the world won't justify it to 1 million businesses >> running php 4 code which is reliant on $_REQUEST behind the scenes. >> >> although it would generate a tonne of freelance work :p > > that code has to change for 5.3 or 6.0 anyway. > > now is the time to yank out some of the legacy crap. we don't want PHP > to be like windows, do we? The more stuff like this we remove, the harder it becomes for people to quickly move to newer, faster and more secure versions of PHP. That causes way more frustration for everyone than a few "ugly" legacy features. If there is a decent technical reason, performance or security, then we need to take a hard look at it. In this case, the thing we should be looking at isn't whether we should remove $_REQUEST but whether we should remove cookie data from it. Many configurations already do that, including all of my own, and there is a strong valid security reason for not including cookies in $_REQUEST. Most people use $_REQUEST to mean GET or POST, not realizing that it could also contain cookies and as such bad guys could potentially do some cookie injection tricks and break naive applications. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Segfault while looping through hash table
On 15.05.2009 07:31, Farley Knight wrote:
> while (zend_hash_get_current_data(Z_ARRVAL(zhash), (void**)&value)
> == SUCCESS) {
> current++;
> printf("Currently on entry %d\n", current);
> if (zend_hash_move_forward(Z_ARRVAL(zhash)) == SUCCESS)
> printf("Done moving hash forward. Result was successful\n");
> else
> printf("Done moving hash forward. Result was a failure\n");
> }
What's the point of this if() ?
You continue reading the values even if move_forward() fails (i.e. the end is
reached).
--
Wbr,
Antony Dovgal
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.2.10
On Thu, May 14, 2009 at 21:25, Lester Caine wrote: > Hannes Magnusson wrote: >> >> On Thu, May 14, 2009 at 18:45, Lester Caine wrote: >>> Since 5.3 DOES require some work to port legacy applications over >> >> Do you have a quick list of things that is required so we can document >> them, or maybe even fix? > > Several hundred warnings that are not present currently? Please be more precise. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
