#43402 [Com]: FILTER_VALIDATE_EMAIL is not RFC2822 compliant
ID: 43402
Comment by: matt at mattfarina dot com
Reported By: nobody at example dot org
Status: Open
Bug Type: Filter related
Operating System: *
PHP Version: 5.2.5
New Comment:
Please correct me if I'm wrong but isn't localhost an alias and RFC
2822 requires a fully qualified domain name or IP address. That would be
the issue with [EMAIL PROTECTED]
Previous Comments:
[2008-09-16 19:37:41] drewish at katherinehouse dot com
The current code also bounces valid email addresses like
"[EMAIL PROTECTED]". I haven't been able to test out the suggested regex.
[2007-11-26 14:23:55] nobody at example dot org
Updated test, php_filter_validate_email() returns string on success.
Surely bool would be a more appropriate return value for a logic filter?
Updated regex above fixes the specific issue I was having, I'm
uncertain about other edge cases ([EMAIL PROTECTED]@example.org)?
--TEST--
Bug 43402, RFC2822 allows chars (?, =) in dot-atoms
--SKIPIF--
--FILE--
--EXPECT--
bool(true)
[2007-11-26 11:34:19] nobody at example dot org
I may be missing something about the unit tests, following regex update
to php_filter_validate_email() will not pass my test case (after doing
rm ext/filter/tests/*.o ext/filter/tests/*.lo, clearing .out .log .exp
.diff from tests and doing make; make test).
const char regexp[] =
"/^((\\\"[^\\\"\\f\\n\\r\\t\\b]+\\\")|([\\w\\!\\#\\$\\%\\&\\'\\*\\+\\-\\~\\/\\^\\`\\|\\{\\}\\=\\?]+(\\.[\\w\\!\\#\\$\\%\\&\\'\\*\\+\\-\\~\\/\\^\\`\\|\\{\\}\\=\\?]+)*))@((\\[(((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9]))\\.((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9]))\\.((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9]))\\.((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9])))\\])|(((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9]))\\.((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9]))\\.((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9]))\\.((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9])))|((([A-Za-z0-9\\-])+\\.)+[A-Za-z\\-]+))$/D";
Yet the equivalent regex works as expected in both PHP and my patched
install.
true,
'[EMAIL PROTECTED]'=>false,
"!#$%&'*+-/=.?^_`{|[EMAIL PROTECTED]"=>true,
);
$failed = 0;
$fail = array();
foreach ($test as $k => $v){
if (!(validate_email($k) === $v)){
$failed++;
$fail[].= $k;
}
}
if ($failed > 0){
echo "Failed $failed of ",count($test), " tests using PHP func\n";
print_r($fail);
}
$failed = 0;
$fail = array();
foreach ($test as $k => $v){
if (!((bool)filter_var($k, FILTER_VALIDATE_EMAIL) == (bool)$v)){
$failed++;
$fail[].= $k;
}
}
if ($failed > 0){
echo "Failed $failed of ",count($test), " tests using filter
func\n";
print_r($fail);
}
[2007-11-25 23:46:34] nobody at example dot org
--TEST--
RFC2822 conformance for local atoms
--SKIPIF--
--FILE--
--EXPECT--
bool(true)
# Apologies for bug spam
[2007-11-25 22:22:59] nobody at example dot org
Description:
The regex used in php_filter_validate_email does not permit all valid
atom chars from RFC2822 (eg: ASCII 61, 63).
Reproduce code:
---
http://bugs.php.net/?id=43402&edit=1
#43402 [Com]: FILTER_VALIDATE_EMAIL is not RFC2822 compliant
ID: 43402
Comment by: matt at mattfarina dot com
Reported By: nobody at example dot org
Status: Open
Bug Type: Filter related
Operating System: *
PHP Version: 5.2.5
New Comment:
RFC 2822 allows for email addresses like [EMAIL PROTECTED] or
[EMAIL PROTECTED] But, RFC 2821 (SMTP Standard) does not allow for those.
See sections 4.1.2 and 4.13 for more detail.
The question with email addresses is should we support RFC 2822 or
2821? For routing FILTER_VALIDATE_EMAIL currently follows RFC 2821.
Previous Comments:
[2008-09-16 20:00:59] matt at mattfarina dot com
Please correct me if I'm wrong but isn't localhost an alias and RFC
2822 requires a fully qualified domain name or IP address. That would be
the issue with [EMAIL PROTECTED]
[2008-09-16 19:37:41] drewish at katherinehouse dot com
The current code also bounces valid email addresses like
"[EMAIL PROTECTED]". I haven't been able to test out the suggested regex.
[2007-11-26 14:23:55] nobody at example dot org
Updated test, php_filter_validate_email() returns string on success.
Surely bool would be a more appropriate return value for a logic filter?
Updated regex above fixes the specific issue I was having, I'm
uncertain about other edge cases ([EMAIL PROTECTED]@example.org)?
--TEST--
Bug 43402, RFC2822 allows chars (?, =) in dot-atoms
--SKIPIF--
--FILE--
--EXPECT--
bool(true)
[2007-11-26 11:34:19] nobody at example dot org
I may be missing something about the unit tests, following regex update
to php_filter_validate_email() will not pass my test case (after doing
rm ext/filter/tests/*.o ext/filter/tests/*.lo, clearing .out .log .exp
.diff from tests and doing make; make test).
const char regexp[] =
"/^((\\\"[^\\\"\\f\\n\\r\\t\\b]+\\\")|([\\w\\!\\#\\$\\%\\&\\'\\*\\+\\-\\~\\/\\^\\`\\|\\{\\}\\=\\?]+(\\.[\\w\\!\\#\\$\\%\\&\\'\\*\\+\\-\\~\\/\\^\\`\\|\\{\\}\\=\\?]+)*))@((\\[(((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9]))\\.((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9]))\\.((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9]))\\.((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9])))\\])|(((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9]))\\.((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9]))\\.((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9]))\\.((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9])))|((([A-Za-z0-9\\-])+\\.)+[A-Za-z\\-]+))$/D";
Yet the equivalent regex works as expected in both PHP and my patched
install.
true,
'[EMAIL PROTECTED]'=>false,
"!#$%&'*+-/=.?^_`{|[EMAIL PROTECTED]"=>true,
);
$failed = 0;
$fail = array();
foreach ($test as $k => $v){
if (!(validate_email($k) === $v)){
$failed++;
$fail[].= $k;
}
}
if ($failed > 0){
echo "Failed $failed of ",count($test), " tests using PHP func\n";
print_r($fail);
}
$failed = 0;
$fail = array();
foreach ($test as $k => $v){
if (!((bool)filter_var($k, FILTER_VALIDATE_EMAIL) == (bool)$v)){
$failed++;
$fail[].= $k;
}
}
if ($failed > 0){
echo "Failed $failed of ",count($test), " tests using filter
func\n";
print_r($fail);
}
[2007-11-25 23:46:34] nobody at example dot org
--TEST--
RFC2822 conformance for local atoms
--SKIPIF--
--FILE--
--EXPECT--
bool(true)
# Apologies for bug spam
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/43402
--
Edit this bug report at http://bugs.php.net/?id=43402&edit=1
#46139 [Com]: PDOStatement->setFetchMode() forgets FETCH_PROPS_LATE
ID: 46139
Comment by: matt at mattfarina dot com
Reported By: chsc at peytz dot dk
Status: Open
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.3.0alpha2
New Comment:
I've found this same problem in PHP 5.2.6.
Previous Comments:
[2008-09-20 19:46:57] chsc at peytz dot dk
Suggested fix:
Index: ext/pdo/pdo_stmt.c
===
RCS file: /repository/php-src/ext/pdo/pdo_stmt.c,v
retrieving revision 1.118.2.38.2.24.2.22
diff -u -8 -p -r1.118.2.38.2.24.2.22 pdo_stmt.c
--- ext/pdo/pdo_stmt.c 12 Aug 2008 17:20:25 -
1.118.2.38.2.24.2.22
+++ ext/pdo/pdo_stmt.c 20 Sep 2008 19:44:43 -
@@ -902,24 +902,25 @@ static int do_fetch_opt_finish(pdo_stmt_
}
/* }}} */
/* perform a fetch. If do_bind is true, update any bound columns.
* If return_value is not null, store values into it according to HOW.
*/
static int do_fetch(pdo_stmt_t *stmt, int do_bind, zval
*return_value,
enum pdo_fetch_type how, enum pdo_fetch_orientation ori, long
offset, zval *return_all TSRMLS_DC) /* {{{ */
{
- int flags = how & PDO_FETCH_FLAGS, idx, old_arg_count = 0;
+ int flags, idx, old_arg_count = 0;
zend_class_entry *ce = NULL, *old_ce = NULL;
zval grp_val, *grp, **pgrp, *retval, *old_ctor_args = NULL;
int colno;
if (how == PDO_FETCH_USE_DEFAULT) {
how = stmt->default_fetch_type;
}
+ flags = how & PDO_FETCH_FLAGS;
how = how & ~PDO_FETCH_FLAGS;
if (!do_fetch_common(stmt, ori, offset, do_bind TSRMLS_CC)) {
return 0;
}
if (how == PDO_FETCH_BOUND) {
RETVAL_TRUE;
Inspired by the fix for bug 41971:
http://cvs.php.net/viewvc.cgi/php-src/ext/pdo/pdo_stmt.c?r1=1.118.2.38.2.21&r2=1.118.2.38.2.22
[2008-09-20 19:43:53] chsc at peytz dot dk
Description:
PDO::FETCH_PROPS_LATE only works if it specified in both the
$stmt->setFetchMode() call and in the following $stmt->fetch().
Calling
$stmt->setFetchMode(PDO::FETCH_CLASS | PDO::FETCH_PROPS_LATE,
'MyClass');
$obj = $stmt->fetch();
yields the same result as
$stmt->setFetchMode(PDO::FETCH_CLASS, 'MyClass');
$obj$stmt->fetch();
In order to make it work you should specify FETCH_PROPS_LATE in both
calls, i.e.
$stmt->setFetchMode(PDO::FETCH_CLASS | PDO::FETCH_PROPS_LATE,
'MyClass');
$obj = $stmt->fetch(PDO::FETCH_CLASS | PDO::FETCH_PROPS_LATE);
Reproduce code:
---
class Person {
public $name = NULL;
public function __construct() {
var_dump($this->name);
}
}
$db = new PDO("mysql:dbname=foo", "foo", "secret");
$db->exec("CREATE TABLE person (id INTEGER NOT NULL, name
VARCHAR(100))");
$db->exec("INSERT INTO person (id, name) VALUES (1, 'Sven')");
$stmt1 = $db->query('SELECT * FROM person');
$stmt1->setFetchMode(PDO::FETCH_CLASS | PDO::FETCH_PROPS_LATE,
'Person');
$obj1 = $stmt1->fetch(PDO::FETCH_CLASS | PDO::FETCH_PROPS_LATE);
var_dump($obj1->name);
$stmt1 = NULL;
$stmt2 = $db->query('SELECT * FROM person');
$stmt2->setFetchMode(PDO::FETCH_CLASS | PDO::FETCH_PROPS_LATE,
'Person');
$obj2 = $stmt2->fetch();
var_dump($obj2->name);
Expected result:
NULL
string(4) "Sven"
NULL
string(4) "Sven"
Actual result:
--
NULL
string(4) "Sven"
string(4) "Sven"
string(4) "Sven"
--
Edit this bug report at http://bugs.php.net/?id=46139&edit=1
