Re: [PHP-DEV] Strict session?
Hi, I strongly recommend to submit the Strict session patch for php-src(HEAD) because the vulnerability of PHP against the session adoption/fixation attack is annoying issue of the PHP programmers for many years. I also suggest to apply this patch for PHP_5_4 after PHP 5.4.0 is released. For PHP 5.4.1, I suggest that the default value of session.use_strict_mode should be 0 (Off) to maintain the backward compatibility. Rui Yasuo Ohgaki wrote: Hi all, Few years ago, I have proposed strict session. It seems PHP 5.4 and php-src don't have protection against session adoption yet. Since there will be many TLDs, session adoption attack will be very easy for some domains until browsers support them. Even without new TLDs, attacker may place cookie file to attack session adoption or can exploit paths or domains, since there is no standard for precedence. e.g. Domain has more precedence over path on Chrome while path has greater precedence on IE. This is due to the order difference of sent cookies. (If there are multiple cookies are set for domain/path, only one became the outstanding cookie. I think PHP uses first IIRC while other implementation may use the last. Therefore, browser may not able to solve this issue, since it may destroy apps specific to browser) Even if a programmer sets path and domain for PHP session id cookie, attackers may exploit this to fix session id with session managers that are vulnerable to session adoption. If you don't get idea, play with cookie with/without domain/path is set/unset. You'll see how attacker may use session adoption. Default session module's configuration (domain not set, path set to /) is very easy to exploit anyway. I usually set both exact application domain/path, and unset all domain/path cookies for session id to prevent the attack. I guess this is not widely adopted. Even this is not enough. For example, if subdomain is added, Chrome has greater precedence for subdomain and attacker may exploit it. I pasted a patch for PHP 5.2 that rejects uninitialized session id. I think original patch was written by Stefan Esser. It is for PHP 5.2, but it's easy to port to current PHP. If one would like to old behavior, he/she can just turn off the strict session. There are too many ways to exploit session with session adoption vulnerable session manger. Simple solution is making session manager strict. Any comments? -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Multibyte support
Hi, It is almost same for me. What kind of configure option you are using ? For me (Ubuntu 11.10), if I made PHP-5.4 with 'configure --enable-mbstring', it works fine. But, if I made it with 'configure --enable-mbstring --with-apxs2=/usr/bin/apxs2', a Shift_JIS encoded PHP script causes the parser error. For both cases, zend.multibyte and zend.script_encoding can be specified. I believe that it was OK in Ubuntu 11.04 with the same option (--with-axps2). Rui Yasuo Ohgaki wrote: Hi all, I noticed that Zend Multibyte Support won't be on with ./sapi/cli/php -d zend.multibyte=1 nor zend.multibyte=on (in php.ini) This happens both php-src and php-src-5.4. According to php.ini-production from php-src: ; If enabled, scripts may be written in encodings that are incompatible with ; the scanner. CP936, Big5, CP949 and Shift_JIS are the examples of such ; encodings. To use this feature, mbstring extension must be enabled. ; Default: Off ;zend.multibyte = Off I thought it became runtime option. Is this a bug or am I missing something? -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] proposal for change the argument of parse_str/mb_parse_str
Hello, I think the second argument of parse_str/mb_parse_str should be changed from optional to mandatory. parse_str(string encoded_string [, array result]) - parse_str(string encoded_string , array result) It is to reduce the risk of vulnerability, and it has neary same risk as register_globals which is removed from PHP 5.4. The vulnerability against code injection attack found in a recent version of phpMyAdmin is just a example. http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-2505 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-2506 The current implementation of parse_str changes the active symbol table in the function. I think that it has the possible security risk like, http://www.php-security.org/MOPB/MOPB-26-2007.html The side effect is that thhe old code like parse_str($query_string) should be changed, but, I think it is good direction to improve the security. Rui -- Rui Hirokawa hirok...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] adding RFC3984 support to http_build_query
Hello,
I made a patch to add the RFC-3984 based url-encoding support
into http_build_query().
The http_build_query() is quite useful, but,
it isn't based on the official url-encoding scheme (RFC-3984)
for ~ (tilde) and ' '(space).
I added an optional (the 4th) parameter 'is_rfc3984'.
If it is true (false by default, now), RFC3984 based
url-encoding scheme (it is same as rawurlencode() ) is used.
A simple example shown as bellow,
$v = array('foo'='m o','boo'='[^~]');
// result: foo=m+pboo=%5B%5E%7E5D
echo http_build_query($v, null, '');
// result: foo=m%20pboo=%5B%5E~5D (RFC-3986 compatible)
echo http_build_query($v, null, '', true);
// result: foo=m%20pboo=%5B%5E~5D (RFC-3986 compatible)
echo rawurlencode($v['foo']).''.rawurlencode($v['boo']);
I'm going to commit the patch if it is accepted.
Rui
Index: ext/standard/basic_functions.c
===
--- ext/standard/basic_functions.c (revision 307112)
+++ ext/standard/basic_functions.c (working copy)
@@ -1513,6 +1513,7 @@
ZEND_ARG_INFO(0, formdata)
ZEND_ARG_INFO(0, prefix)
ZEND_ARG_INFO(0, arg_separator)
+ ZEND_ARG_INFO(0, is_rfc3986)
ZEND_END_ARG_INFO()
/* }}} */
/* {{{ image.c */
Index: ext/standard/php_http.h
===
--- ext/standard/php_http.h (revision 307112)
+++ ext/standard/php_http.h (working copy)
@@ -28,7 +28,7 @@
const char *num_prefix, int num_prefix_len,
const char *key_prefix, int key_prefix_len,
const char *key_suffix, int key_suffix_len,
- zval *type, char *arg_sep TSRMLS_DC);
+ zval *type, char *arg_sep, int is_rfc3986
TSRMLS_DC);
#define php_url_encode_hash(ht, formstr) php_url_encode_hash_ex((ht),
(formstr), NULL, 0, NULL, 0, NULL, 0, NULL TSRMLS_CC)
PHP_FUNCTION(http_build_query);
Index: ext/standard/http.c
===
--- ext/standard/http.c (revision 307112)
+++ ext/standard/http.c (working copy)
@@ -29,7 +29,7 @@
const char *num_prefix, int num_prefix_len,
const char *key_prefix, int key_prefix_len,
const char *key_suffix, int key_suffix_len,
- zval *type, char *arg_sep TSRMLS_DC)
+ zval *type, char *arg_sep, int is_rfc3986 TSRMLS_DC)
{
char *key = NULL, *ekey, *newprefix, *p;
int arg_sep_len, key_len, ekey_len, key_type, newprefix_len;
@@ -81,7 +81,11 @@
}
if (Z_TYPE_PP(zdata) == IS_ARRAY || Z_TYPE_PP(zdata) ==
IS_OBJECT) {
if (key_type == HASH_KEY_IS_STRING) {
- ekey = php_url_encode(key, key_len, ekey_len);
+ if (is_rfc3986) {
+ ekey = php_raw_url_encode(key, key_len,
ekey_len);
+ } else {
+ ekey = php_url_encode(key, key_len,
ekey_len);
+ }
newprefix_len = key_suffix_len + ekey_len +
key_prefix_len + 3 /* %5B */;
newprefix = emalloc(newprefix_len + 1);
p = newprefix;
@@ -132,7 +136,7 @@
*p = '\0';
}
ht-nApplyCount++;
- php_url_encode_hash_ex(HASH_OF(*zdata), formstr, NULL,
0, newprefix, newprefix_len, %5D, 3, (Z_TYPE_PP(zdata) == IS_OBJECT ? *zdata
: NULL), arg_sep TSRMLS_CC);
+ php_url_encode_hash_ex(HASH_OF(*zdata), formstr, NULL,
0, newprefix, newprefix_len, %5D, 3, (Z_TYPE_PP(zdata) == IS_OBJECT ? *zdata
: NULL), arg_sep, is_rfc3986 TSRMLS_CC);
ht-nApplyCount--;
efree(newprefix);
} else if (Z_TYPE_PP(zdata) == IS_NULL || Z_TYPE_PP(zdata) ==
IS_RESOURCE) {
@@ -145,7 +149,11 @@
/* Simple key=value */
smart_str_appendl(formstr, key_prefix, key_prefix_len);
if (key_type == HASH_KEY_IS_STRING) {
- ekey = php_url_encode(key, key_len, ekey_len);
+ if (is_rfc3986) {
+ ekey = php_raw_url_encode(key, key_len,
ekey_len);
+ } else {
+ ekey = php_url_encode(key, key_len,
ekey_len);
+ }
smart_str_appendl(formstr, ekey, ekey_len);
efree(ekey);
} else {
@@ -161,7 +169,11 @@
Re: [PHP-DEV] [PATCH] adding RFC3984 support to http_build_query
Hello,
Thank you for the comment.
How about adding two PHP constant,
PHP_QUERY_RFC1738 (default) and PHP_QUERY_RFC3986 ?
It is like,
echo http_build_query($v, null, '');
echo http_build_query($v, null, '',PHP_QUERY_RFC1738);
echo http_build_query($v, null, '', PHP_QUERY_RFC3986);
Rui
(2011/01/05 21:17), Tjerk Meesters wrote:
Instead of a boolean, could you add a rfc-xx selection parameter
instead, like, in case one would like rfc 3986 instead?
On Jan 5, 2011 8:10 PM, Rui Hirokawa rui_hirok...@yahoo.co.jp
mailto:rui_hirok...@yahoo.co.jp wrote:
Hello,
I made a patch to add the RFC-3984 based url-encoding support
into http_build_query().
The http_build_query() is quite useful, but,
it isn't based on the official url-encoding scheme (RFC-3984)
for ~ (tilde) and ' '(space).
I added an optional (the 4th) parameter 'is_rfc3984'.
If it is true (false by default, now), RFC3984 based
url-encoding scheme (it is same as rawurlencode() ) is used.
A simple example shown as bellow,
$v = array('foo'='m o','boo'='[^~]');
// result: foo=m+pboo=%5B%5E%7E5D
echo http_build_query($v, null, '');
// result: foo=m%20pboo=%5B%5E~5D (RFC-3986 compatible)
echo http_build_query($v, null, '', true);
// result: foo=m%20pboo=%5B%5E~5D (RFC-3986 compatible)
echo rawurlencode($v['foo']).''.rawurlencode($v['boo']);
I'm going to commit the patch if it is accepted.
Rui
Re: [PHP-DEV] [PATCH] adding RFC3984 support to http_build_query
Hello,
This is a revised patch based on the PHP constant.
Rui
(2011/01/05 21:50), Rui Hirokawa wrote:
Hello,
Thank you for the comment.
How about adding two PHP constant,
PHP_QUERY_RFC1738 (default) and PHP_QUERY_RFC3986 ?
It is like,
echo http_build_query($v, null, '');
echo http_build_query($v, null, '',PHP_QUERY_RFC1738);
echo http_build_query($v, null, '', PHP_QUERY_RFC3986);
Rui
(2011/01/05 21:17), Tjerk Meesters wrote:
Instead of a boolean, could you add a rfc-xx selection parameter
instead, like, in case one would like rfc 3986 instead?
On Jan 5, 2011 8:10 PM, Rui Hirokawa rui_hirok...@yahoo.co.jp
mailto:rui_hirok...@yahoo.co.jp wrote:
Hello,
I made a patch to add the RFC-3984 based url-encoding support
into http_build_query().
The http_build_query() is quite useful, but,
it isn't based on the official url-encoding scheme (RFC-3984)
for ~ (tilde) and ' '(space).
I added an optional (the 4th) parameter 'is_rfc3984'.
If it is true (false by default, now), RFC3984 based
url-encoding scheme (it is same as rawurlencode() ) is used.
A simple example shown as bellow,
$v = array('foo'='m o','boo'='[^~]');
// result: foo=m+pboo=%5B%5E%7E5D
echo http_build_query($v, null, '');
// result: foo=m%20pboo=%5B%5E~5D (RFC-3986 compatible)
echo http_build_query($v, null, '', true);
// result: foo=m%20pboo=%5B%5E~5D (RFC-3986 compatible)
echo rawurlencode($v['foo']).''.rawurlencode($v['boo']);
I'm going to commit the patch if it is accepted.
Rui
Index: ext/standard/basic_functions.c
===
--- ext/standard/basic_functions.c (revision 307112)
+++ ext/standard/basic_functions.c (working copy)
@@ -1513,6 +1513,7 @@
ZEND_ARG_INFO(0, formdata)
ZEND_ARG_INFO(0, prefix)
ZEND_ARG_INFO(0, arg_separator)
+ ZEND_ARG_INFO(0, enc_type)
ZEND_END_ARG_INFO()
/* }}} */
/* {{{ image.c */
@@ -3531,6 +3532,8 @@
REGISTER_LONG_CONSTANT(PHP_URL_PATH, PHP_URL_PATH, CONST_CS |
CONST_PERSISTENT);
REGISTER_LONG_CONSTANT(PHP_URL_QUERY, PHP_URL_QUERY, CONST_CS |
CONST_PERSISTENT);
REGISTER_LONG_CONSTANT(PHP_URL_FRAGMENT, PHP_URL_FRAGMENT, CONST_CS |
CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT(PHP_QUERY_RFC1738, PHP_QUERY_RFC1738, CONST_CS
| CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT(PHP_QUERY_RFC3986, PHP_QUERY_RFC3986, CONST_CS
| CONST_PERSISTENT);
#define REGISTER_MATH_CONSTANT(x) REGISTER_DOUBLE_CONSTANT(#x, x, CONST_CS |
CONST_PERSISTENT)
REGISTER_MATH_CONSTANT(M_E);
Index: ext/standard/php_http.h
===
--- ext/standard/php_http.h (revision 307112)
+++ ext/standard/php_http.h (working copy)
@@ -28,7 +28,7 @@
const char *num_prefix, int num_prefix_len,
const char *key_prefix, int key_prefix_len,
const char *key_suffix, int key_suffix_len,
- zval *type, char *arg_sep TSRMLS_DC);
+ zval *type, char *arg_sep, int enc_type
TSRMLS_DC);
#define php_url_encode_hash(ht, formstr) php_url_encode_hash_ex((ht),
(formstr), NULL, 0, NULL, 0, NULL, 0, NULL TSRMLS_CC)
PHP_FUNCTION(http_build_query);
Index: ext/standard/http.c
===
--- ext/standard/http.c (revision 307112)
+++ ext/standard/http.c (working copy)
@@ -29,7 +29,7 @@
const char *num_prefix, int num_prefix_len,
const char *key_prefix, int key_prefix_len,
const char *key_suffix, int key_suffix_len,
- zval *type, char *arg_sep TSRMLS_DC)
+ zval *type, char *arg_sep, int enc_type TSRMLS_DC)
{
char *key = NULL, *ekey, *newprefix, *p;
int arg_sep_len, key_len, ekey_len, key_type, newprefix_len;
@@ -81,7 +81,11 @@
}
if (Z_TYPE_PP(zdata) == IS_ARRAY || Z_TYPE_PP(zdata) ==
IS_OBJECT) {
if (key_type == HASH_KEY_IS_STRING) {
- ekey = php_url_encode(key, key_len, ekey_len);
+ if (enc_type == PHP_QUERY_RFC3986) {
+ ekey = php_raw_url_encode(key, key_len,
ekey_len);
+ } else {
+ ekey = php_url_encode(key, key_len,
ekey_len);
+ }
newprefix_len = key_suffix_len + ekey_len +
key_prefix_len + 3 /* %5B */;
newprefix = emalloc(newprefix_len + 1);
p = newprefix;
@@ -132,7 +136,7 @@
*p = '\0';
}
ht-nApplyCount
Re: [PHP-DEV] PHP 4.4.9 Released!
There are a typo in NEWS of PHP 4.4.9. #37421 should be #27421. fixed bug #27421 (by david at dfoerster dot de) mbstring.func_overload set in .htaccess becomes global Rui On Thu, 7 Aug 2008 14:09:47 -0700 Chris Stockton [EMAIL PROTECTED] wrote: Hello, Is the link in the changelog pointing to the wrong bug? Seems mb related but speaks of mysqli. Just something small I noticed. -Chris -- Rui Hirokawa [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_3) / Zend.m4 zend.c zend_compile.c zend_globals.h zend_highlight.c zend_language_scanner.c zend_language_scanner.h zend_language_scanner.l zend_l
Derick, Thank you for bug report. I found a very sinple scipt (t1.php, shown below) causes segmentation error or stack error using PHP 5.3 compiled with --enable-zend-multibyte. It works fine with PHP 5.2. php.ini --- mbstring.internal_encoding = UTF-8 mbstring.script_encoding = SJIS -- t1.php ?php $az=a; ? Current implementation of zend-multibyte for PHP 5.3 is ported from PHP 5.2 with minimal changes. I think that the incompatibilities between flex and re2c cause the problem. Marcus, Do you have any comments ? Rui On Thu, 3 Jul 2008 10:04:30 +0200 (CEST) Derick Rethans [EMAIL PROTECTED] wrote: On Sun, 29 Jun 2008, Rui Hirokawa wrote: hirokawaSun Jun 29 08:21:36 2008 UTC Modified files: (Branch: PHP_5_3) /ZendEngine2Zend.m4 zend.c zend_compile.c zend_globals.h zend_highlight.c zend_language_scanner.c zend_language_scanner.h zend_language_scanner.l zend_language_scanner_defs.h zend_multibyte.h Log: implemented again zend-multibyte for PHP 5.3 I found a bug with this, run the attached script with both multi-byte on and off, and you'll see it. regards, Derick -- Rui Hirokawa [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New flame
Hello Marcus, The script encoding is specified by a couple of different ways. (1) mbstinrg.script_encoding in php.ini (2) declare(encopding=Shift_JIS) on each PHP script - multibyte_encoding_001.phpt (3) BOM in Unicode script - multibyte_encoding_00[23].phpt (4) auto detection based on mbstring.language,mbstring.detect_order The test scripts are already existing for (2),(3), but nothing for (1),(4). I already confirmed my patch for PHP 5.3 is working for (1),(2) for Shift_JIS encoding. But, I didn't confirmed yet for Unicode BOM and other encodings. Could you put your confirmation of (1) into a test? And is there any detection functionality missing to write those tests? A test script 'ext/mbstring/tests/zend-multibyte.phpt' is already existing since PHP 4.3, but, I think it should be better put into Zend/tests/multibyte/ I commited multibyte_encoding_00[45].phpt based on zend-multibyte.phpt into Zend/tests/multibyte/ The encoding detection is based on, 1. mbstring.script_encoding in php.ini 2. declare(encoding=) in the script 3. BOM in Unicode (UTF-8, UTF-16) All of these are alrady covered by the current test scrpts. Rui -- Rui Hirokawa [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] towards a 5.3 release
Hello, 3) re2c Rui recently came to the list with notes on the ZE MB feature [7]. @Scott/Marcus: Is this enough for you guys to get this working? @Rui: Is there any chance you can get more people in the japanese (or asian in general) community involved here? I hope that we can have more people as testers. I will disscuss this problem on japanese develoepers mailing list. Derick already found a bug. I will try to fix the bug soon. I hope that PHP developpers in non-asian country also evaluate the zend-multibyte because zend-multibute also support single-byte encodings. Rui -- Rui Hirokawa [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Adding new encodings to mbstring?
Hello, encoding conversion engine of mbstring is implemented in libmbfl library, which is developped in sourceforge.jp as php-i18n. http://sourceforge.jp/projects/php-i18n/ Adding new encodings is widely accepted. If you have a patch to add a new encoding please send me. I will commit the patch into libmbl and mbstring after simple inspection. Rui On Sat, 28 Jun 2008 22:12:07 -0400 Haluk AKIN [EMAIL PROTECTED] wrote: Hi all, Is it possible to add new character encodings to mbstring? http://us.php.net/mbstring If it is possible, then is there a procedure where I can submit new feature requests? Or is it possible for me to add the new character encodings myself? Thanks, Haluk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Rui Hirokawa [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New flame
Removing multibyte encoding support from PHP 5.3 will cause the severe incompatibility problem with the older PHP 5.x. As Stefan noted, Shift_JIS character encoding which is widely used in Japan is not flex safe encoding because it includes 0x5c (backslash) as second byte of a multibyte character. BIG5 character encoding used by Chinese is also non flex safe encoding. Today, I committed a patch for zend multibyte support into PHP_5_3. It is still in experimental staus because I am not an expert of re2c/flex. A couple of test scripts is already existing in Zend/tests/multibyte/*.phpt, but, of course, we need more test scripts for zend multibute. (we need to have TestFesta in Japan :) ) The script encoding is specified by a couple of different ways. (1) mbstinrg.script_encoding in php.ini (2) declare(encopding=Shift_JIS) on each PHP script - multibyte_encoding_001.phpt (3) BOM in Unicode script - multibyte_encoding_00[23].phpt (4) auto detection based on mbstring.language,mbstring.detect_order The test scripts are already existing for (2),(3), but nothing for (1),(4). I already confirmed my patch for PHP 5.3 is working for (1),(2) for Shift_JIS encoding. But, I didn't confirmed yet for Unicode BOM and other encodings. We need to have more test scripts to maintain the reliability, to minimize security risks. Rui On Tue, 24 Jun 2008 16:21:33 +0200 Stefan Esser [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is used when reading scripts that are in encodings like Shift-JIS which is very common in Japan. In any case, I have tried to get involvement from some people I know over there without much success. I've asked around a bit as well with our customers/partners, and all they seem to answer is we simply use UTF-8. It is very unlikely that anyone on internals uses Shift-JIS (EUC-xx). Mainly because (nearly) noone here is Japanese (Korean, Chinese). However google for phpinfo() and you will see that zend_multibyte is compiled into several PHP servers. You can also google for Shift-JIS and co... The problem here is that newer Asian systems will use UTF-8 (except those nations using characters not possible in utf-8) and therefore the customers of the PHP developers (on this list) will not need that support. However there are many legacy systems out there who depend on this feature. They most probably don't know about this discussion or internals at all, so they cannot speak up. If PHP 5.3 drops this feature it might close some multibyte security problems. However this also means that all those Japanese/Chinese/Korean/Taiwanese/... multibyte scripts will not run anymore. This forces systems to stay on PHP 5.2 which will most probably don't get security updates once PHP 5.3 is out of the door. Stefan Esser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhhAu0ACgkQSuF5XhWr2njCswCcDCyWnFi4jInpX+BPhmSp6ec7 pAEAoKfDzhhpFKifgwlsn99WMwkve5bp =2qIJ -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Rui Hirokawa [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: RE : [PHP-DEV] Re: RE : [PATCH] zend-multibyte unicode detection vs. __halt_compiler()
Changing 'detect_unicode' disabled as default is a possible solution.
But, it might cause some backward incompatibility issues.
If no one gives any objection within a coupled of days,
I will commit the change ('detect_unicode' will be disabled by default).
Rui
On Thu, 27 Sep 2007 18:37:57 +0200
LAUPRETRE François (P) [EMAIL PROTECTED] wrote:
From: Rui Hirokawa [mailto:[EMAIL PROTECTED]
1.set detect_unicode = Off
2.adding declare(encoding=encoding_name) on the first line
of script can be your solution ?
The 'declare' statement is not a solution because unicode detection is done
before it is seen. So, PHK and PHAR remain incompatible with zend_multibyte.
Can you confirm that unicode detection does not exist in PHP 6 (keeping only
'declare' statements) ?
As a workaround in PHP 5, would it be possible to add a 'detect_unicode=off'
line in php.ini-dist and php.ini-recommended ?
Regards
Francois
--
Rui Hirokawa [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RE : [PATCH] zend-multibyte unicode detection vs. __halt_compiler()
Hi, The declare() semantic like, declare(encoding=Shift_JIS); is already supported by mbstring since PHP 4.3. 1.set detect_unicode = Off 2.adding declare(encoding=encoding_name) on the first line of script can be your solution ? Rui On Fri, 07 Sep 2007 14:40:14 -0500 Greg Beaver [EMAIL PROTECTED] wrote: LAUPRETRE Fran輟is (P) wrote: Hi, From: Rui Hirokawa IMHO, #42396 is not a bug, but it is the specification. The normal script doesn't contain a null byte if it is not encoded in Unicode. It is understandable the addition of a unique byte seqence '0x' detection to support PHAR/PHK, but it is a change to add a new feature. Sorry to insist but, since __halt_compiler() was introduced, your assertion is not true any more. Actually, it depends on what you consider as 'the script' : if you just consider the data from the beginning of the file to the __halt_compiler() directive, that's right: if this data contains a null byte, it is unicode. But the current unicode detection is not aware of the __halt_compiler() directive, and it scans the whole file. So, your assertion is wrong: it is perfectly legitimate to have a non-unicode script contain null bytes (if they are after an __halt_compiler() directive). So, it is a bug and not a feature request. This side effect was not identified when __halt_compiler() was added. The obvious solution is to decide that a non-unicode script cannot contain null bytes, even after an __halt_compiler(). It would just require three lines in the PHP doc. But that would introduce a severe limitation and, in practice, would make the __halt_compiler() feature almost useless. The solution I am proposing is not very elegant but it is the only one I found which does not make __halt_compiler() and multibyte incompatible. As __halt_compiler() was introduced recently, and as, afaict, the only software to use it are PHAR and PHK, I consider it as acceptable, if not perfect. Greg, Marcus, do you have a better idea ? I considered that unicode detection is done before __halt_compiler() can be detected, do you confirm ? unicode detection in mb_string is in fact done before __halt_compiler(). I don't think there is a solution to this problem without changes to PHP. Fortunately, PHP 6 introduces usage of declare (please correct me if I'm wrong) that allows declaration of the file's encoding, which would remove the guesswork. I think the best thing in this case is to recommend that multibyte auto-detection be disabled, and wait for PHP 6 which provides a proper solution to the unicode encoding issue. Greg -- Rui Hirokawa [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] zend-multibyte unicode detection vs. __halt_compiler()
Hi,
IMHO, #42396 is not a bug, but it is the specification.
The normal script doesn't contain a null byte if it is not encoded in Unicode.
It is understandable the addition of a unique byte seqence
'0x' detection to support PHAR/PHK,
but it is a change to add a new feature.
Rui
On Thu, 23 Aug 2007 18:58:52 +0200
LAUPRETRE Fran輟is (P) [EMAIL PROTECTED] wrote:
Hi,
Here is a patch I am submitting to fix bug #42396 (PHP 5).
The problem: when PHP is configured with the '--enable-zend-multibyte'
option, it tries to autodetect unicode-encoded scripts. Then, if a script
contains null bytes after an __halt_compiler() directive, it will be
considered as UTF-16 or 32, and the execution typically results in a lot of
'?' garbage. In practice, it makes PHK and PHAR incompatible with the
zend-multibyte feature.
The only workaround was to turn off the (undocumented) 'detect_unicode' flag.
But it is not a real solution, as people may want to use unicode detection
along with PHK/PHAR packages, and there's no logical reason to keep them
incompatible.
The patch I am submitting assumes that a document encoded in UTF-8, UTF-16,
or UTF-32 cannot contain a sequence of four 0xff bytes. So, it adds a small
detection loop before scanning the script for null bytes. If a sequence of 4
0xff is found, the unicode detection is aborted and the script is considered
as non unicode, whatever other binary data it can contain. Of course, this
detection happens after looking for a byte-order mark.
Now, I can modify the PHK_Creator tool to set 4 0xff bytes after the
__halt_compiler() directive, which makes the generated PHK archives
compatible with zend-multibyte. The same for PHAR.
It would be better if we could scan the script for null bytes only up to the
__halt_compiler() directive, but I suspect it to be impossible as it is not
yet compiled...
Regards
Francois
--- zend_multibyte.c.old2007-01-01 10:35:46.0 +0100
+++ zend_multibyte.c2007-08-23 17:22:24.0 +0200
@@ -1035,6 +1035,7 @@
zend_encoding *script_encoding = NULL;
int bom_size;
char *script;
+ unsigned char *p,*p_end;
if (LANG_SCNG(script_org_size) sizeof(BOM_UTF32_LE)-1) {
return NULL;
@@ -1069,6 +1070,18 @@
return script_encoding;
}
+ /* Search for four 0xff bytes - if found, script cannot be unicode */
+
+ p=(unsigned char *)LANG_SCNG(script_org);
+ p_end=(p+LANG_SCNG(script_org_size)-3);
+ while (p p_end) {
+ if ( ((* p) ==(unsigned char)0x0ff)
+((*(p+1))==(unsigned char)0x0ff)
+((*(p+2))==(unsigned char)0x0ff)
+((*(p+3))==(unsigned char)0x0ff)) return NULL;
+ p++;
+ }
+
/* script contains NULL bytes - auto-detection */
if (memchr(LANG_SCNG(script_org), 0, LANG_SCNG(script_org_size))) {
/* make best effort if BOM is missing */
--
Rui Hirokawa [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php6: input encoding, filter and making JIT really JIT
I think #2 is better than #1. The current implementation of mbstring is based on the solution similar to #1. It is simple and stable, but, #2 has more flexibility. Rui On Thu, 14 Dec 2006 21:59:44 +0100 Pierre [EMAIL PROTECTED] wrote: Hello, Yesterday, Ilia, Andrei and I discussed the possible solutions to solve the input encoding in php6 (unicode). I will try to describe them here. I do not go too deep in the details, the goal is to choose one solution and then propose a patch to test. Our preference goes to the solution #2. -- Solution #1: The idea here is to detect encoding, encode and register the variable during the request initialization (before the script gets the hand). Besides the encoding detection, it is how it works in the actual implementation (all php versions). * Init - Parse the request into an array. - locate _charset_ or use unicode.request_encoding - filter/decode/register the variable like it is done now * Runtime Just like now, the auto_globals (with or without jit) are declared and ready to be used. This solution has one advantage, it requires only a few changes in the engine. The request processing functions need to be changed to detect the encoding. The main disadvantages are: - the lack of flexibility, encoding must be set before the script gets the hand, using vhost config or htaccess - the possible bad encoding detection will force the user to manually parse the raw request (when available). Solution #2: add (true) JIT support for GET/POST/COOKIE/... Instead of doing all the precessing during the init phase, it will be done on demand when a input variable is requested, at runtime. * Init - don't parse the request but simply store it for later processing * Runtime - when a input variable is fetched: - encoding is defined using unicode.request_encoding - filter/decode/register the complete array (post,get,...) The way JIT works has to be changed. It has to process the data at runtime instead of register them at compile time. This is the only way to be sure that the users has set the input encoding correctly (or has the opportunity to set it). The main advantage of this solution is the absence of magic for the user. The encoding detection can be checked and/or set in time by the user before the input processing, it is safe and flexible. I would also suggest to add a function: filter_input_encoding($type) to define the encoding type at runtime instead of using ini_set (which is often disabled). There is no real technical disadvantages but requires more work and changes in the engine. But these changes will also bring some more performance improvements (if (0) $t = $_ENV['foo']; will not trigger jit). -- I would like to hear your ideas, opinions and comments. Especially about the possible changes in the engine. Feel free to ask more details if my explanations were unclear :) Regards, --Pierre -- Rui Hirokawa [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RFC: about mb_list_encoding() /mb_list_encodings_alias_names( ), mb_list_mime_names( )
Hi Derick, Currently, we are discussing about the specification of mb_list_encoding () and some other related functions such as mb_list_encodings_alias_names(), mb_list_mime_names() on mailing list for Japanese PHP developers. In mbstring, the encoding is defined in the three ways (1.character encoding,2.its alias, 3.MIME encoding). mb_list_encoding() returns the list of supported character encodings in mbstring, but, it doesn't return the alias and MIME encoding. The list of alias and MIME encoding are also useful for us. mb_list_encodings_alias_names(), mb_list_mime_names() are recently added as new functions in PHP_5_2 branch. mb_list_encodings_alias_names() returns the supported list of alias encoding. mb_list_mime_names() returns the supported list of MIME encoding. The other solution to support list of alias and MIME encoding is adding an option to mb_list_encoding() such as mb_list_encodings([int type]) type : MB_ENCODING_LISTS_ALL (returns encodings, alias, MIME) MB_ENCODING_LISTS_ALIAS (returns alias) MB_ENCODING_LISTS_MIME (returns mime) MB_ENCODING_LISTS_ENTITY (returns encodings, default for backward compatibility) I know you wrote the function mb_list_encoding() in 2004. -- Revision 1.211 Mon Mar 8 22:18:03 2004 UTC by derick Branch: MAIN - Added mb_list_encoding() to return an array with all mbstring supported encodings. -- What do you think about the specification ? Which way do you prefer to support alias/MIME encoding? 1. adding new functions (mb_list_encodings_alias_names(), mb_list_mime_names()) 2. adding an option to mb_list_encoding(). Regards, Rui Hirokawa -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6.0 Wishlist
+1 bundling the opcode cache like APC. I also wish some elemental debugging features (stack dump, etc.) like Xdebug has. Rui On Fri, 12 Aug 2005 10:48:20 -0700 Rasmus Lerdorf [EMAIL PROTECTED] wrote: Since we are breaking a lot of stuff in 6.0, at least with Unicode_semantics=On I am wondering if it may not be time to break some more stuff and do a bit of spring cleaning. It would mean many apps would need some work to work on PHP 6, but at the same time I think it is work people would welcome since it would mostly involve removing hacks instead of adding them. And yes, I know this is pretty controversial, so take a few deep breaths before replying, please. -- Rui Hirokawa [EMAIL PROTECTED] -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.338 / Virus Database: 267.10.8/71 - Release Date: 2005/08/12 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Implementing support for HTTP Digest Authorization in PHP
I checked this problem again, and I found getallheaders() can have authorization even if safe_mode is On. So, $_SERVER['PHP_AUTH_DIGEST'] in my patch is not necessary to use with PEAR::Auth_HTTP and Apache. I am not sure it is useful or not with another SAPI such as ISAPI. Rui HTTP Digest Authorization is supported by PEAR::Auth_HTTP. But, as you said, it cannot be used when safe_mode = On. To solve this problem, I made a simple patch based on your suggestion based on php5 CVS HEAD. Applying this patch, we can access $_SERVER['PHP_AUTH_DIGEST'] , which will be like, 'Digest username=taro, realm=php-users-digest, nonce=MTExMTkwNjQ2OA==399347e5e0e2688ede69bfe5e707e3a3, uri=/php/auth/test_digest_simple.php, algorithm=MD5, response=6ba162b80d63f8960c73405519cea861, opaque=b7d192a44e0da16cd180ebe85efb7c8f, qop=auth, nc=0001, cnonce=082c875dcb2ca740'. The Digest Authentication can be performed in Auth_HTTP using this server variable. Some utility function such as http_digest_params() to decode parameters from $_SERVER['PHP_AUTH_DIGEST'] will be also useful to make the authentication code. I hope apply this patch into CVS HEAD if there is no objection. Rui -- Rui Hirokawa [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Implementing support for HTTP Digest Authorization in PHP
(BHTTP Digest Authorization is supported by PEAR::Auth_HTTP. (BBut, as you said, it cannot be used when safe_mode = On. (B (BTo solve this problem, (BI made a simple patch based on your suggestion based on php5 CVS HEAD. (BApplying this patch, we can access $_SERVER['PHP_AUTH_DIGEST'] , (Bwhich will be like, (B'Digest username="taro", realm="php-users-digest", (Bnonce="MTExMTkwNjQ2OA==399347e5e0e2688ede69bfe5e707e3a3", (Buri="/php/auth/test_digest_simple.php", algorithm=MD5, (Bresponse="6ba162b80d63f8960c73405519cea861", (Bopaque="b7d192a44e0da16cd180ebe85efb7c8f", qop=auth, nc=0001, (Bcnonce="082c875dcb2ca740"'. (B (BThe Digest Authentication can be performed in Auth_HTTP using this (Bserver variable. (B (BSome utility function such as http_digest_params() to decode (Bparameters from $_SERVER['PHP_AUTH_DIGEST'] will be also useful (Bto make the authentication code. (B (BI hope apply this patch into CVS HEAD if there is no objection. (B (BRui (B (BOn Wed, 23 Mar 2005 08:44:14 +0100 (BLacaK [EMAIL PROTECTED] wrote: (B (B Hi everybody, (B I am looking for somebody, who can implement HTTP Digest Authorization (B in PHP. (B A solution, that could be useful also for many PHP users. (is more (B secure and so more usable than Basic authorization) (B (B "HTTP Basic Authorization" sends password only base64 encoded, and may (B be easily stolen. (B but (B "HTTP Digest Authorization" sends password 'md5 hashed', so for other (B script it is much more harder to steal or gain it. (B (B Wouldn$B%((Bt it be possible to add in PHP support the Digest Authorization (B for example in a form $_SERVER["PHP_AUTH_DIGEST"], where the header from (B HTTP (B Response would be added if 'Authorization: Digest ...' is used (similar (B as the 'Authorization: (B Basic ...' in $_SERVER["PHP_AUTH_USER"] and $_SERVER["PHP_AUTH_PW"] even (B when safe_mode=On) (B (B 1.PHP must parse HTTP header. (B 2. When it finds Authorization: Basic then fill up (B $_SERVER["PHP_AUTH_USER"] and $_SERVER["PHP_AUTH_PW"] (B 3. add next condition When it finds Authorization: Digest then fill (B $_SERVER["PHP_AUTH_DIGEST"] (B (I think, that it takes only few lines of source code . Modification in (B init_request_info() function in mod_php4.c + ?) (B (B I appended short file, where this modification is marked. (B (B Thank you very much for your time and effort. (B Please reply. Or advice me who I should contact. (B Laco (B (B-- (BRui Hirokawa [EMAIL PROTECTED]-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring internal encoding behavior
Japanese multibyte encoding and Unicode, and some singlebyte encodings are supported by mbstring up to PHP 4.2.x. From 4.3.x, the Korean and Chinese multibyte encoding are also supported, and the language setting is introduced. You should define mbstring.language in php.ini, mbstring.language = Japanese; for Japanese encoding like Shift_JIS mbstring.language = Korean; for Korean encoding It affects the automatic encoding detection of the user input (POST/GET/Cookie) and the default encoding. Rui On Sat, 04 Dec 2004 15:01:59 -0500 Al Baker [EMAIL PROTECTED] wrote: I've noticed some different behavior between mbstring versions 4.2.2 and 4.3.9 -- both on RedHat 8 -- in terms of how internal encoding affects the script. In 4.2.2, the encoding translation appeared to work okay and would convert Shift_JIS into UTF-8 on incoming requests. We didn't try any other encodings since this was our primary concern and worked well. The internal_encoding setting in the php.ini file was set to UTF-8. Our language file (very simple PHP array with values being the translated text) was in Shift_JIS, and this was no problem to just send this to the browser.We display send the Shift_JIS language file entries to the browser [via Smarty] as well as some other text that is stored in UTF-8 and run through mb_convert_encoding to convert it to Shift_JIS as well. All in all, this works as expected. Now, we're trying to upgrade to php4.3.9 and I can find no easy way to get the Shift_JIS to work in the existing setup, it would just return UTF-8 or garbled characters. In other words, mb_convert_encoding was not doing it's job, and it wouldn't even display the Shift_JIS language file entries. Manually converting the language file from Shift_JIS characters to UTF-8 and then running all the elements through mb_convert_encoding apparently did nothing as well -- unless I first called mb_internal_encoding() and set that to Shift_JIS (likewise, setting this in the php.ini file worked as well). Then, the characters would be displayed correctly in Shift_JIS. I'm not sure if this is the correct behavior though... it seems to me that the internal encoding should almost always be UTF-8 and mb_convert_encoding should work regardless of the internal encoding. -- Rui Hirokawa [EMAIL PROTECTED] -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.289 / Virus Database: 265.4.7 - Release Date: 2004/12/07 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Comparing objects on PHP5
I performed the same test with HEAD (PHP 5.0.0RC3-dev (build: May 9
2004 10:16:50)).
There are no E_NOTICE message now, but, the problems are still existing with
RC2,
PHP 4.3.6
same,not same,not same,same
same,not same,not same,same
PHP 5.0.0-CVS 2004/5/9 (ze1_compatibility_mode = Off)
same,not same,not same,same
not same,not same,not same,same
PHP 5.0.0-CVS 2004/5/9 (ze1_compatibility_mode = On)
same,same,not same,same
not same,not same,not same,not same
Rui
On Sun, 09 May 2004 19:17:35 +0300
Andi Gutmans [EMAIL PROTECTED] wrote:
Did you check HEAD? I fixed something to do with the comparison. if it
still doesn't work please let me know.
Andi
At 04:43 PM 5/9/2004 +0900, Rui Hirokawa wrote:
Hi,
I think objects comparison in PHP5 has problems.
Here is small sample code,
?php
class Foo {
var $v = 1;
}
class Boo {
var $v = 1;
}
$a = new Foo;
$b = new Foo;
$c = new Boo;
$d = new Foo;
$d-v = 2;
$e = $a;
// value comparison
echo $a == $b ? same, : not same,;
echo $a == $c ? same, : not same,;
echo $a == $d ? same, : not same,;
echo $a == $e ? same : not same;
echo \n;
// value and type comparison
echo $a === $b ? same, : not same,;
echo $a === $c ? same, : not same,;
echo $a === $d ? same, : not same,;
echo $a === $e ? same : not same;
?
The output from PHP4 and PHP5(ze1_compat on/off) is,
PHP 4.3.6 :
same,not same,not same,same
same,not same,not same,same
PHP 5.0.0RC2 zend.ze1_compatibility_mode=off :
same,not same,not same,same
(Notice: Object of class [Foo|Boo] could not be converted to integer)
not same,not same,not same,same
PHP 5.0.0RC2 zend.ze1_compatibility_mode=on :
same,same,not same,same
not same,not same,not same,not same
The problem and question are,
1. the different class is recognised as same in PHP5 (ze1_compat=on).
2. the same object is recognised as different in PHP5 (ze1_compat=on).
3. Why integer casting of object was implicitly applied in PHP5
(ze1_compat=off) ?
--
Rui Hirokawa [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Comparing objects on PHP5
Hi,
I think objects comparison in PHP5 has problems.
Here is small sample code,
?php
class Foo {
var $v = 1;
}
class Boo {
var $v = 1;
}
$a = new Foo;
$b = new Foo;
$c = new Boo;
$d = new Foo;
$d-v = 2;
$e = $a;
// value comparison
echo $a == $b ? same, : not same,;
echo $a == $c ? same, : not same,;
echo $a == $d ? same, : not same,;
echo $a == $e ? same : not same;
echo \n;
// value and type comparison
echo $a === $b ? same, : not same,;
echo $a === $c ? same, : not same,;
echo $a === $d ? same, : not same,;
echo $a === $e ? same : not same;
?
The output from PHP4 and PHP5(ze1_compat on/off) is,
PHP 4.3.6 :
same,not same,not same,same
same,not same,not same,same
PHP 5.0.0RC2 zend.ze1_compatibility_mode=off :
same,not same,not same,same
(Notice: Object of class [Foo|Boo] could not be converted to integer)
not same,not same,not same,same
PHP 5.0.0RC2 zend.ze1_compatibility_mode=on :
same,same,not same,same
not same,not same,not same,not same
The problem and question are,
1. the different class is recognised as same in PHP5 (ze1_compat=on).
2. the same object is recognised as different in PHP5 (ze1_compat=on).
3. Why integer casting of object was implicitly applied in PHP5
(ze1_compat=off) ?
--
Rui Hirokawa [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: adding http digest authentication to php5
I forgot to attach a sample script. Rui Hi, I just made a patch to add http digest authentication for php5 based on RFC2617. It is not tested well yet, the attached sample script 'digest-auth.php' works with Mozilla Firebird 0.7. It is useful or not ? Rui -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: adding http digest authentication to php5
Can I attach a php script ?
?php // a sample for digest authentication
$realm=php-users;
$uri = $_SERVER['REQUEST_URI'];
$nonce = time();
$username = taro;
$password = secret;
function auth_func() {
global $realm, $nonce;
header('HTTP/1.0 401 Unauthorized');
header(WWW-authenticate: Digest realm=\$realm\ nonce=\$nonce\);
die('password or user name is invalid.');
}
if (empty($_SERVER['PHP_AUTH_USER'])) {
auth_func();
} else {
$username = $_SERVER['PHP_AUTH_USER'];
$response = $_SERVER['PHP_AUTH_PW'];
$nonce= $_SERVER['PHP_AUTH_NONCE'];
// response based on RFC2617
$a1 = md5($username:$realm:$password);
$a2 = md5(GET:$uri);
$response0 = md5($a1:$nonce:$a2);
print response1:$responsebr /;
print response0:$response0br /;
print nonce:$nonce/br;
if ($response == $response0) {
print authenticated.br /;
} else {
print not authenticated.br /;
}
}
?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: adding http digest authentication to php5
I reallized this patch is not useful, because 1. http 1.1 based client authentication method (qop, cnonce, nc) is not supported yet. array $_SERVER['PHP_AUTH_DIGEST'] having the elementes 'nonce','qop','cnonce','nc' should be defined. 2. the order of parameters should be unknown. I will use Thomas Pike's excellent implementation now. Rui Rui Hirokawa wrote: Hi, I just made a patch to add http digest authentication for php5 based on RFC2617. It is not tested well yet, the attached sample script 'digest-auth.php' works with Mozilla Firebird 0.7. It is useful or not ? Rui -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PATCH] mbstring warning fixes
Thank you for sending patch.
I applied your first patch to cvs, but, the second change
was already applied in cvs.
Rui
On Tue, 11 Nov 2003 15:45:35 +
Joe Orton [EMAIL PROTECTED] wrote:
4.3/ext/mbstring/mbstring.c: In function `php_mb_gpc_encoding_converter':
4.3/ext/mbstring/mbstring.c:3729: warning: `ret' might be used uninitialized in this
function
4.3/ext/mbstring/mbstring.c: In function `php_mb_gpc_encoding_detector':
4.3/ext/mbstring/mbstring.c:3792: warning: `encoding' might be used uninitialized in
this function
I'm not sure what the right fixes are here, e.g. below makes the
warnings go away...
Index: ext/mbstring/mbstring.c
===
RCS file: /repository/php-src/ext/mbstring/mbstring.c,v
retrieving revision 1.142.2.37
diff -u -r1.142.2.37 mbstring.c
--- ext/mbstring/mbstring.c 6 Nov 2003 15:41:36 - 1.142.2.37
+++ ext/mbstring/mbstring.c 11 Nov 2003 15:41:27 -
@@ -3726,7 +3726,7 @@
TSRMLS_DC)
{
int i;
- mbfl_string string, result, *ret;
+ mbfl_string string, result, *ret = NULL;
enum mbfl_no_encoding from_encoding, to_encoding;
mbfl_buffer_converter *convd;
@@ -3789,7 +3789,7 @@
{
mbfl_string string;
enum mbfl_no_encoding *elist;
- enum mbfl_no_encoding encoding;
+ enum mbfl_no_encoding encoding = mbfl_no_encoding_invalid;
mbfl_encoding_detector *identd = NULL;
int size, *list;
--
Rui Hirokawa [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] changes in ext/mbstring (PHP_4_3)
ext/mbstring/mbfilter* and some related files were developed as the general library to convert multi-byte character encoding and these files were bundled with PHP since PHP 4.0.6. The original library is developed as libmbfl in sourceforge.jp. (You can obtain libmbfl from http://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/php-i18n/libmbfl) The bundled files (mbfilter*) with PHP are replaced the bundled version of libmbfl in CVS head branch (PHP5-dev). These changes are to minimize the difference of the original library and the bundled version with PHP and to minimize the developing effort. I have plan to commit the same changes to PHP_4_3 branch. If someone has problem with these changes, please let me know. Rui -- Rui Hirokawa [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] changes in ext/mbstring (PHP_4_3)
Ilia, I understand your opinion. The stable release has priority in PHP_4_3 branch. I will skip to commit for PHP_4_3 branch, and I commit this change for upcoming PHP_4_4 (4.5?) branch. Rui On Sun, 21 Sep 2003 12:26:25 -0400 Ilia Alshanetsky [EMAIL PROTECTED] wrote: PHP_4_3 is strictly for bug fixes, no major changes code and functionality changes should occur to prevent introduction of new bugs into a stable code base. As such, as a 4.3.X Release Master I am strongly opposed to this change. Ilia On September 21, 2003 07:02 am, Rui Hirokawa wrote: ext/mbstring/mbfilter* and some related files were developed as the general library to convert multi-byte character encoding and these files were bundled with PHP since PHP 4.0.6. The original library is developed as libmbfl in sourceforge.jp. (You can obtain libmbfl from http://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/php-i18n/libmbfl) The bundled files (mbfilter*) with PHP are replaced the bundled version of libmbfl in CVS head branch (PHP5-dev). These changes are to minimize the difference of the original library and the bundled version with PHP and to minimize the developing effort. I have plan to commit the same changes to PHP_4_3 branch. If someone has problem with these changes, please let me know. Rui -- Rui Hirokawa [EMAIL PROTECTED] -- Rui Hirokawa [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
