Zend_Validate_Alnum and Zend_Validate_Alpha failing(ZF1.0RC3)

[Joshua Ross]

I posted this once in response to another post and then in my investigation
I found that these validators have changed in 1.0RC3 somewhat
dramatically.We are having problems using Zend_Validate_Alpha and
Zend_Validate_Alnum but only on our production RHEL5 server.  Using xampp
locally on windows XP the same code works perfectly.  Prior to 1.0RC3 this
worked on production as well.  We are running ZF 1.0RC3.  Here is the test
code(similar to original post):

$validator = new Zend_Validate_Alnum();

$vars = array('Alnum' => 'foobar1',
              'notAlnum' => 'foob@r1');
foreach ($vars as $var) {
        echo $validator->isValid($var) ? $var.":true\n":$var.":false\n";
}

RHEL5 response:
foobar1:false
foob@r1:false

WindowsXP response:
foobar1:true
foob@r1:false

Looking at the code both validators now leverage the filters instead of
using ctype functions.  The filters use perl reg exp but even those have
changed.
For example, Zend_Validate_Alnum was:
/[^[:alnum:]]/

and now it is:
/[^\p{L}\p{N}]/u

minus the whitespace logic.  I assume the whitespace logic is why this was
changed.  Testing the new expression using pcretest I am receiving false for
valid strings.

RHEL5 & Windows XP
******
> pcretest
PCRE version 6.6 06-Feb-2006

  re> /[^\p{L}\p{N}]/u
** Unknown option 'u'
  re> /[^\p{L}\p{N}]/
data> foobar1
 0: f
data> foobar
 0: f
data> foobar@1
 0: f

I am quite confused!  Is the regular expression incorrect?  It appears
correct based on my investigation but it is obviously not working. This
failed on both windowsXP and the RHEL5 server, both of which are running
pcretest 6.6.  It did, however, work in my test php script on Windows XP.
The one difference here is that my PHP install on my Windows XP box has PCRE
6.7.  Is this reg exp only available in PCRE 6.7?

I don't have a windows XP 6.7 pcretest at the moment, going to look to see
if cygwin has it ready for download.  Once I test it I will post the
results.  Below are some server details:


RHEL 5 System details:
******************************************************
PHP 5.1.6 (cli) (built: Apr  4 2007 11:38:24)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
    with Zend Extension Manager v1.2.0, Copyright (c) 2003-2006, by Zend
Technologies
    with Zend Optimizer v3.2.6, Copyright (c) 1998-2007, by Zend
Technologies

yum info:
*******
PCRE
---------------------------------------------------------------
pcre.x86_64                              6.6-1.1                installed

PHP
---------------------------------------------------------------
php.x86_64                               5.1.6-11.el5           installed
php-bcmath.x86_64                        5.1.6-11.el5           installed
php-cli.x86_64                           5.1.6-11.el5           installed
php-common.x86_64                        5.1.6-11.el5           installed
php-dba.x86_64                           5.1.6-11.el5           installed
php-devel.x86_64                         5.1.6-11.el5           installed
php-gd.x86_64                            5.1.6-11.el5           installed
php-imap.x86_64                          5.1.6-11.el5           installed
php-ldap.x86_64                          5.1.6-11.el5           installed
php-mbstring.x86_64                      5.1.6-11.el5           installed
php-mysql.x86_64                         5.1.6-11.el5           installed
php-ncurses.x86_64                       5.1.6-11.el5           installed
php-odbc.x86_64                          5.1.6-11.el5           installed
php-pdo.x86_64                           5.1.6-11.el5           installed
php-pear.noarch                          1:1.4.9-4              installed
php-pgsql.x86_64                         5.1.6-11.el5           installed
php-snmp.x86_64                          5.1.6-11.el5           installed
php-soap.x86_64                          5.1.6-11.el5           installed
php-xml.x86_64                           5.1.6-11.el5           installed
php-xmlrpc.x86_64                        5.1.6-11.el5           installed



WindowsXP System details:
**************************************************
PHP 5.2.1 (cli) (built: Feb  7 2007 23:11:26)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
    with Zend Extension Manager v1.0.11, Copyright (c) 2003-2006, by Zend
Technologies
    with Zend Optimizer v3.2.2, Copyright (c) 1998-2006, by Zend
Technologies

PCRE:
*************************************************
PCRE Library Version => 6.7 04-Jul-2006


Josh

[Joshua Ross]

Ok, so I mistook the responses from pcretest and it was returning true.  So
ignoring that I am still unsure why this is failing.


"Joshua Ross" <[hidden email]> wrote in
message news:[hidden email]...

>I posted this once in response to another post and then in my investigation
>I found that these validators have changed in 1.0RC3 somewhat
>dramatically.We are having problems using Zend_Validate_Alpha and
>Zend_Validate_Alnum but only on our production RHEL5 server.  Using xampp
> locally on windows XP the same code works perfectly.  Prior to 1.0RC3 this
> worked on production as well.  We are running ZF 1.0RC3.  Here is the test
> code(similar to original post):
>
> $validator = new Zend_Validate_Alnum();
>
> $vars = array('Alnum' => 'foobar1',
>              'notAlnum' => 'foob@r1');
> foreach ($vars as $var) {
>        echo $validator->isValid($var) ? $var.":true\n":$var.":false\n";
> }
>
> RHEL5 response:
> foobar1:false
> foob@r1:false
>
> WindowsXP response:
> foobar1:true
> foob@r1:false
>
> Looking at the code both validators now leverage the filters instead of
> using ctype functions.  The filters use perl reg exp but even those have
> changed.
> For example, Zend_Validate_Alnum was:
> /[^[:alnum:]]/
>
> and now it is:
> /[^\p{L}\p{N}]/u
>
> minus the whitespace logic.  I assume the whitespace logic is why this was
> changed.  Testing the new expression using pcretest I am receiving false
> for valid strings.
>
> RHEL5 & Windows XP
> ******
>> pcretest
> PCRE version 6.6 06-Feb-2006
>
>  re> /[^\p{L}\p{N}]/u
> ** Unknown option 'u'
>  re> /[^\p{L}\p{N}]/
> data> foobar1
> 0: f
> data> foobar
> 0: f
> data> foobar@1
> 0: f
>
> I am quite confused!  Is the regular expression incorrect?  It appears
> correct based on my investigation but it is obviously not working. This
> failed on both windowsXP and the RHEL5 server, both of which are running
> pcretest 6.6.  It did, however, work in my test php script on Windows XP.
> The one difference here is that my PHP install on my Windows XP box has
> PCRE 6.7.  Is this reg exp only available in PCRE 6.7?
>
> I don't have a windows XP 6.7 pcretest at the moment, going to look to see
> if cygwin has it ready for download.  Once I test it I will post the
> results.  Below are some server details:
>
>
> RHEL 5 System details:
> ******************************************************
> PHP 5.1.6 (cli) (built: Apr  4 2007 11:38:24)
> Copyright (c) 1997-2006 The PHP Group
> Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
>    with Zend Extension Manager v1.2.0, Copyright (c) 2003-2006, by Zend
> Technologies
>    with Zend Optimizer v3.2.6, Copyright (c) 1998-2007, by Zend
> Technologies
>
> yum info:
> *******
> PCRE
> ---------------------------------------------------------------
> pcre.x86_64                              6.6-1.1                installed
>
> PHP
> ---------------------------------------------------------------
> php.x86_64                               5.1.6-11.el5           installed
> php-bcmath.x86_64                        5.1.6-11.el5           installed
> php-cli.x86_64                           5.1.6-11.el5           installed
> php-common.x86_64                        5.1.6-11.el5           installed
> php-dba.x86_64                           5.1.6-11.el5           installed
> php-devel.x86_64                         5.1.6-11.el5           installed
> php-gd.x86_64                            5.1.6-11.el5           installed
> php-imap.x86_64                          5.1.6-11.el5           installed
> php-ldap.x86_64                          5.1.6-11.el5           installed
> php-mbstring.x86_64                      5.1.6-11.el5           installed
> php-mysql.x86_64                         5.1.6-11.el5           installed
> php-ncurses.x86_64                       5.1.6-11.el5           installed
> php-odbc.x86_64                          5.1.6-11.el5           installed
> php-pdo.x86_64                           5.1.6-11.el5           installed
> php-pear.noarch                          1:1.4.9-4              installed
> php-pgsql.x86_64                         5.1.6-11.el5           installed
> php-snmp.x86_64                          5.1.6-11.el5           installed
> php-soap.x86_64                          5.1.6-11.el5           installed
> php-xml.x86_64                           5.1.6-11.el5           installed
> php-xmlrpc.x86_64                        5.1.6-11.el5           installed
>
>
>
> WindowsXP System details:
> **************************************************
> PHP 5.2.1 (cli) (built: Feb  7 2007 23:11:26)
> Copyright (c) 1997-2007 The PHP Group
> Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
>    with Zend Extension Manager v1.0.11, Copyright (c) 2003-2006, by Zend
> Technologies
>    with Zend Optimizer v3.2.2, Copyright (c) 1998-2006, by Zend
> Technologies
>
> PCRE:
> *************************************************
> PCRE Library Version => 6.7 04-Jul-2006
>
>
> Josh
>
>
>
>

[Darby Felton]

Hi Joshua,

My comments are inline below:

Joshua Ross wrote:

> I posted this once in response to another post and then in my investigation
> I found that these validators have changed in 1.0RC3 somewhat
> dramatically.We are having problems using Zend_Validate_Alpha and
> Zend_Validate_Alnum but only on our production RHEL5 server.  Using xampp
> locally on windows XP the same code works perfectly.  Prior to 1.0RC3 this
> worked on production as well.  We are running ZF 1.0RC3.  Here is the test
> code(similar to original post):
>
> $validator = new Zend_Validate_Alnum();
>
> $vars = array('Alnum' => 'foobar1',
>               'notAlnum' => 'foob@r1');
> foreach ($vars as $var) {
>         echo $validator->isValid($var) ? $var.":true\n":$var.":false\n";
> }
>
> RHEL5 response:
> foobar1:false
> foob@r1:false
>
> WindowsXP response:
> foobar1:true
> foob@r1:false
>
> Looking at the code both validators now leverage the filters instead of
> using ctype functions.  The filters use perl reg exp but even those have
> changed.
> For example, Zend_Validate_Alnum was:
> /[^[:alnum:]]/
>
> and now it is:
> /[^\p{L}\p{N}]/u
>
> minus the whitespace logic.  I assume the whitespace logic is why this was
> changed.  Testing the new expression using pcretest I am receiving false for
> valid strings.

No, the regular expression was changed in order to support UTF-8
strings. Note the "u" modifier and the UTF-8 property checks ("L" for
letter, "N" for number).

>
> RHEL5 & Windows XP
> ******
>> pcretest
> PCRE version 6.6 06-Feb-2006
>
>   re> /[^\p{L}\p{N}]/u
> ** Unknown option 'u'
>   re> /[^\p{L}\p{N}]/
> data> foobar1
>  0: f
> data> foobar
>  0: f
> data> foobar@1
>  0: f

Hmm, interesting. It appears that on this system the UTF-8 support is
not available.

> I am quite confused!  Is the regular expression incorrect?  It appears
> correct based on my investigation but it is obviously not working. This
> failed on both windowsXP and the RHEL5 server, both of which are running
> pcretest 6.6.  It did, however, work in my test php script on Windows XP.
> The one difference here is that my PHP install on my Windows XP box has PCRE
> 6.7.  Is this reg exp only available in PCRE 6.7?

No, I have been unable to reproduce the problem through unit testing on
the following platforms:

* PHP 5.1.4, WinXP, PCRE 6.6

* PHP 5.2.1, Ubuntu, PCRE 6.7

> I don't have a windows XP 6.7 pcretest at the moment, going to look to see
> if cygwin has it ready for download.  Once I test it I will post the
> results.  Below are some server details:

Thank you for posting these results. It appears that we need some more
investigation to find the root cause of the problem... calling all
volunteers!

Best regards,
Darby

>
>
> RHEL 5 System details:
> ******************************************************
> PHP 5.1.6 (cli) (built: Apr  4 2007 11:38:24)
> Copyright (c) 1997-2006 The PHP Group
> Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
>     with Zend Extension Manager v1.2.0, Copyright (c) 2003-2006, by Zend
> Technologies
>     with Zend Optimizer v3.2.6, Copyright (c) 1998-2007, by Zend
> Technologies
>
> yum info:
> *******
> PCRE
> ---------------------------------------------------------------
> pcre.x86_64                              6.6-1.1                installed
>
> PHP
> ---------------------------------------------------------------
> php.x86_64                               5.1.6-11.el5           installed
> php-bcmath.x86_64                        5.1.6-11.el5           installed
> php-cli.x86_64                           5.1.6-11.el5           installed
> php-common.x86_64                        5.1.6-11.el5           installed
> php-dba.x86_64                           5.1.6-11.el5           installed
> php-devel.x86_64                         5.1.6-11.el5           installed
> php-gd.x86_64                            5.1.6-11.el5           installed
> php-imap.x86_64                          5.1.6-11.el5           installed
> php-ldap.x86_64                          5.1.6-11.el5           installed
> php-mbstring.x86_64                      5.1.6-11.el5           installed
> php-mysql.x86_64                         5.1.6-11.el5           installed
> php-ncurses.x86_64                       5.1.6-11.el5           installed
> php-odbc.x86_64                          5.1.6-11.el5           installed
> php-pdo.x86_64                           5.1.6-11.el5           installed
> php-pear.noarch                          1:1.4.9-4              installed
> php-pgsql.x86_64                         5.1.6-11.el5           installed
> php-snmp.x86_64                          5.1.6-11.el5           installed
> php-soap.x86_64                          5.1.6-11.el5           installed
> php-xml.x86_64                           5.1.6-11.el5           installed
> php-xmlrpc.x86_64                        5.1.6-11.el5           installed
>
>
>
> WindowsXP System details:
> **************************************************
> PHP 5.2.1 (cli) (built: Feb  7 2007 23:11:26)
> Copyright (c) 1997-2007 The PHP Group
> Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
>     with Zend Extension Manager v1.0.11, Copyright (c) 2003-2006, by Zend
> Technologies
>     with Zend Optimizer v3.2.2, Copyright (c) 1998-2006, by Zend
> Technologies
>
> PCRE:
> *************************************************
> PCRE Library Version => 6.7 04-Jul-2006
>
>
> Josh
>
>
>
>

[Darby Felton]

Hi Josh,

Maybe this helps you get UTF-8 support on your system?

http://drupal.org/node/40961

We should likely put detection of such support into the class in order
to prevent such problems from happening in the future. Would you mind
filing a bug report, or shall I do it for us?

Best regards,
Darby

Joshua Ross wrote:

> I posted this once in response to another post and then in my investigation
> I found that these validators have changed in 1.0RC3 somewhat
> dramatically.We are having problems using Zend_Validate_Alpha and
> Zend_Validate_Alnum but only on our production RHEL5 server.  Using xampp
> locally on windows XP the same code works perfectly.  Prior to 1.0RC3 this
> worked on production as well.  We are running ZF 1.0RC3.  Here is the test
> code(similar to original post):
>
> $validator = new Zend_Validate_Alnum();
>
> $vars = array('Alnum' => 'foobar1',
>               'notAlnum' => 'foob@r1');
> foreach ($vars as $var) {
>         echo $validator->isValid($var) ? $var.":true\n":$var.":false\n";
> }
>
> RHEL5 response:
> foobar1:false
> foob@r1:false
>
> WindowsXP response:
> foobar1:true
> foob@r1:false
>
> Looking at the code both validators now leverage the filters instead of
> using ctype functions.  The filters use perl reg exp but even those have
> changed.
> For example, Zend_Validate_Alnum was:
> /[^[:alnum:]]/
>
> and now it is:
> /[^\p{L}\p{N}]/u
>
> minus the whitespace logic.  I assume the whitespace logic is why this was
> changed.  Testing the new expression using pcretest I am receiving false for
> valid strings.
>
> RHEL5 & Windows XP
> ******
>> pcretest
> PCRE version 6.6 06-Feb-2006
>
>   re> /[^\p{L}\p{N}]/u
> ** Unknown option 'u'
>   re> /[^\p{L}\p{N}]/
> data> foobar1
>  0: f
> data> foobar
>  0: f
> data> foobar@1
>  0: f
>
> I am quite confused!  Is the regular expression incorrect?  It appears
> correct based on my investigation but it is obviously not working. This
> failed on both windowsXP and the RHEL5 server, both of which are running
> pcretest 6.6.  It did, however, work in my test php script on Windows XP.
> The one difference here is that my PHP install on my Windows XP box has PCRE
> 6.7.  Is this reg exp only available in PCRE 6.7?
>
> I don't have a windows XP 6.7 pcretest at the moment, going to look to see
> if cygwin has it ready for download.  Once I test it I will post the
> results.  Below are some server details:
>
>
> RHEL 5 System details:
> ******************************************************
> PHP 5.1.6 (cli) (built: Apr  4 2007 11:38:24)
> Copyright (c) 1997-2006 The PHP Group
> Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
>     with Zend Extension Manager v1.2.0, Copyright (c) 2003-2006, by Zend
> Technologies
>     with Zend Optimizer v3.2.6, Copyright (c) 1998-2007, by Zend
> Technologies
>
> yum info:
> *******
> PCRE
> ---------------------------------------------------------------
> pcre.x86_64                              6.6-1.1                installed
>
> PHP
> ---------------------------------------------------------------
> php.x86_64                               5.1.6-11.el5           installed
> php-bcmath.x86_64                        5.1.6-11.el5           installed
> php-cli.x86_64                           5.1.6-11.el5           installed
> php-common.x86_64                        5.1.6-11.el5           installed
> php-dba.x86_64                           5.1.6-11.el5           installed
> php-devel.x86_64                         5.1.6-11.el5           installed
> php-gd.x86_64                            5.1.6-11.el5           installed
> php-imap.x86_64                          5.1.6-11.el5           installed
> php-ldap.x86_64                          5.1.6-11.el5           installed
> php-mbstring.x86_64                      5.1.6-11.el5           installed
> php-mysql.x86_64                         5.1.6-11.el5           installed
> php-ncurses.x86_64                       5.1.6-11.el5           installed
> php-odbc.x86_64                          5.1.6-11.el5           installed
> php-pdo.x86_64                           5.1.6-11.el5           installed
> php-pear.noarch                          1:1.4.9-4              installed
> php-pgsql.x86_64                         5.1.6-11.el5           installed
> php-snmp.x86_64                          5.1.6-11.el5           installed
> php-soap.x86_64                          5.1.6-11.el5           installed
> php-xml.x86_64                           5.1.6-11.el5           installed
> php-xmlrpc.x86_64                        5.1.6-11.el5           installed
>
>
>
> WindowsXP System details:
> **************************************************
> PHP 5.2.1 (cli) (built: Feb  7 2007 23:11:26)
> Copyright (c) 1997-2007 The PHP Group
> Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
>     with Zend Extension Manager v1.0.11, Copyright (c) 2003-2006, by Zend
> Technologies
>     with Zend Optimizer v3.2.2, Copyright (c) 1998-2006, by Zend
> Technologies
>
> PCRE:
> *************************************************
> PCRE Library Version => 6.7 04-Jul-2006
>
>
> Josh
>
>
>
>

[Joshua Ross]

I can file the bug report.
I'll take a look at the link you posted here and report back as well,
thanks!!
Josh


"Darby Felton" <[hidden email]> wrote in message
news:[hidden email]...

> Hi Josh,
>
> Maybe this helps you get UTF-8 support on your system?
>
> http://drupal.org/node/40961
>
> We should likely put detection of such support into the class in order
> to prevent such problems from happening in the future. Would you mind
> filing a bug report, or shall I do it for us?
>
> Best regards,
> Darby
>
> Joshua Ross wrote:
>> I posted this once in response to another post and then in my
>> investigation
>> I found that these validators have changed in 1.0RC3 somewhat
>> dramatically.We are having problems using Zend_Validate_Alpha and
>> Zend_Validate_Alnum but only on our production RHEL5 server.  Using xampp
>> locally on windows XP the same code works perfectly.  Prior to 1.0RC3
>> this
>> worked on production as well.  We are running ZF 1.0RC3.  Here is the
>> test
>> code(similar to original post):
>>
>> $validator = new Zend_Validate_Alnum();
>>
>> $vars = array('Alnum' => 'foobar1',
>>               'notAlnum' => 'foob@r1');
>> foreach ($vars as $var) {
>>         echo $validator->isValid($var) ? $var.":true\n":$var.":false\n";
>> }
>>
>> RHEL5 response:
>> foobar1:false
>> foob@r1:false
>>
>> WindowsXP response:
>> foobar1:true
>> foob@r1:false
>>
>> Looking at the code both validators now leverage the filters instead of
>> using ctype functions.  The filters use perl reg exp but even those have
>> changed.
>> For example, Zend_Validate_Alnum was:
>> /[^[:alnum:]]/
>>
>> and now it is:
>> /[^\p{L}\p{N}]/u
>>
>> minus the whitespace logic.  I assume the whitespace logic is why this
>> was
>> changed.  Testing the new expression using pcretest I am receiving false
>> for
>> valid strings.
>>
>> RHEL5 & Windows XP
>> ******
>>> pcretest
>> PCRE version 6.6 06-Feb-2006
>>
>>   re> /[^\p{L}\p{N}]/u
>> ** Unknown option 'u'
>>   re> /[^\p{L}\p{N}]/
>> data> foobar1
>>  0: f
>> data> foobar
>>  0: f
>> data> foobar@1
>>  0: f
>>
>> I am quite confused!  Is the regular expression incorrect?  It appears
>> correct based on my investigation but it is obviously not working. This
>> failed on both windowsXP and the RHEL5 server, both of which are running
>> pcretest 6.6.  It did, however, work in my test php script on Windows XP.
>> The one difference here is that my PHP install on my Windows XP box has
>> PCRE
>> 6.7.  Is this reg exp only available in PCRE 6.7?
>>
>> I don't have a windows XP 6.7 pcretest at the moment, going to look to
>> see
>> if cygwin has it ready for download.  Once I test it I will post the
>> results.  Below are some server details:
>>
>>
>> RHEL 5 System details:
>> ******************************************************
>> PHP 5.1.6 (cli) (built: Apr  4 2007 11:38:24)
>> Copyright (c) 1997-2006 The PHP Group
>> Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
>>     with Zend Extension Manager v1.2.0, Copyright (c) 2003-2006, by Zend
>> Technologies
>>     with Zend Optimizer v3.2.6, Copyright (c) 1998-2007, by Zend
>> Technologies
>>
>> yum info:
>> *******
>> PCRE
>> ---------------------------------------------------------------
>> pcre.x86_64                              6.6-1.1                installed
>>
>> PHP
>> ---------------------------------------------------------------
>> php.x86_64                               5.1.6-11.el5           installed
>> php-bcmath.x86_64                        5.1.6-11.el5           installed
>> php-cli.x86_64                           5.1.6-11.el5           installed
>> php-common.x86_64                        5.1.6-11.el5           installed
>> php-dba.x86_64                           5.1.6-11.el5           installed
>> php-devel.x86_64                         5.1.6-11.el5           installed
>> php-gd.x86_64                            5.1.6-11.el5           installed
>> php-imap.x86_64                          5.1.6-11.el5           installed
>> php-ldap.x86_64                          5.1.6-11.el5           installed
>> php-mbstring.x86_64                      5.1.6-11.el5           installed
>> php-mysql.x86_64                         5.1.6-11.el5           installed
>> php-ncurses.x86_64                       5.1.6-11.el5           installed
>> php-odbc.x86_64                          5.1.6-11.el5           installed
>> php-pdo.x86_64                           5.1.6-11.el5           installed
>> php-pear.noarch                          1:1.4.9-4              installed
>> php-pgsql.x86_64                         5.1.6-11.el5           installed
>> php-snmp.x86_64                          5.1.6-11.el5           installed
>> php-soap.x86_64                          5.1.6-11.el5           installed
>> php-xml.x86_64                           5.1.6-11.el5           installed
>> php-xmlrpc.x86_64                        5.1.6-11.el5           installed
>>
>>
>>
>> WindowsXP System details:
>> **************************************************
>> PHP 5.2.1 (cli) (built: Feb  7 2007 23:11:26)
>> Copyright (c) 1997-2007 The PHP Group
>> Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
>>     with Zend Extension Manager v1.0.11, Copyright (c) 2003-2006, by Zend
>> Technologies
>>     with Zend Optimizer v3.2.2, Copyright (c) 1998-2006, by Zend
>> Technologies
>>
>> PCRE:
>> *************************************************
>> PCRE Library Version => 6.7 04-Jul-2006
>>
>>
>> Josh
>>
>>
>>
>>
>

[Darby Felton]

Hi Josh,

The reason that it is failing for you appears to be that your PCRE does
not have UTF-8 support compiled in. This is likely the result of the
particular distribution not having used the --enable-utf8 option.

What this means to us is that the class should become aware of whether
such support is available, and act accordingly.

I'll go ahead and file a JIRA issue for this so that users of
distributions that do not have PCRE UTF-8 support may still use the
affected classes (though of course without UTF-8 support :) ).

Best regards,
Darby


Joshua Ross wrote:

> Ok, so I mistook the responses from pcretest and it was returning true.  So
> ignoring that I am still unsure why this is failing.
>
>
> "Joshua Ross" <[hidden email]> wrote in
> message news:[hidden email]...
>> I posted this once in response to another post and then in my investigation
>> I found that these validators have changed in 1.0RC3 somewhat
>> dramatically.We are having problems using Zend_Validate_Alpha and
>> Zend_Validate_Alnum but only on our production RHEL5 server.  Using xampp
>> locally on windows XP the same code works perfectly.  Prior to 1.0RC3 this
>> worked on production as well.  We are running ZF 1.0RC3.  Here is the test
>> code(similar to original post):
>>
>> $validator = new Zend_Validate_Alnum();
>>
>> $vars = array('Alnum' => 'foobar1',
>>              'notAlnum' => 'foob@r1');
>> foreach ($vars as $var) {
>>        echo $validator->isValid($var) ? $var.":true\n":$var.":false\n";
>> }
>>
>> RHEL5 response:
>> foobar1:false
>> foob@r1:false
>>
>> WindowsXP response:
>> foobar1:true
>> foob@r1:false
>>
>> Looking at the code both validators now leverage the filters instead of
>> using ctype functions.  The filters use perl reg exp but even those have
>> changed.
>> For example, Zend_Validate_Alnum was:
>> /[^[:alnum:]]/
>>
>> and now it is:
>> /[^\p{L}\p{N}]/u
>>
>> minus the whitespace logic.  I assume the whitespace logic is why this was
>> changed.  Testing the new expression using pcretest I am receiving false
>> for valid strings.
>>
>> RHEL5 & Windows XP
>> ******
>>> pcretest
>> PCRE version 6.6 06-Feb-2006
>>
>>  re> /[^\p{L}\p{N}]/u
>> ** Unknown option 'u'
>>  re> /[^\p{L}\p{N}]/
>> data> foobar1
>> 0: f
>> data> foobar
>> 0: f
>> data> foobar@1
>> 0: f
>>
>> I am quite confused!  Is the regular expression incorrect?  It appears
>> correct based on my investigation but it is obviously not working. This
>> failed on both windowsXP and the RHEL5 server, both of which are running
>> pcretest 6.6.  It did, however, work in my test php script on Windows XP.
>> The one difference here is that my PHP install on my Windows XP box has
>> PCRE 6.7.  Is this reg exp only available in PCRE 6.7?
>>
>> I don't have a windows XP 6.7 pcretest at the moment, going to look to see
>> if cygwin has it ready for download.  Once I test it I will post the
>> results.  Below are some server details:
>>
>>
>> RHEL 5 System details:
>> ******************************************************
>> PHP 5.1.6 (cli) (built: Apr  4 2007 11:38:24)
>> Copyright (c) 1997-2006 The PHP Group
>> Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
>>    with Zend Extension Manager v1.2.0, Copyright (c) 2003-2006, by Zend
>> Technologies
>>    with Zend Optimizer v3.2.6, Copyright (c) 1998-2007, by Zend
>> Technologies
>>
>> yum info:
>> *******
>> PCRE
>> ---------------------------------------------------------------
>> pcre.x86_64                              6.6-1.1                installed
>>
>> PHP
>> ---------------------------------------------------------------
>> php.x86_64                               5.1.6-11.el5           installed
>> php-bcmath.x86_64                        5.1.6-11.el5           installed
>> php-cli.x86_64                           5.1.6-11.el5           installed
>> php-common.x86_64                        5.1.6-11.el5           installed
>> php-dba.x86_64                           5.1.6-11.el5           installed
>> php-devel.x86_64                         5.1.6-11.el5           installed
>> php-gd.x86_64                            5.1.6-11.el5           installed
>> php-imap.x86_64                          5.1.6-11.el5           installed
>> php-ldap.x86_64                          5.1.6-11.el5           installed
>> php-mbstring.x86_64                      5.1.6-11.el5           installed
>> php-mysql.x86_64                         5.1.6-11.el5           installed
>> php-ncurses.x86_64                       5.1.6-11.el5           installed
>> php-odbc.x86_64                          5.1.6-11.el5           installed
>> php-pdo.x86_64                           5.1.6-11.el5           installed
>> php-pear.noarch                          1:1.4.9-4              installed
>> php-pgsql.x86_64                         5.1.6-11.el5           installed
>> php-snmp.x86_64                          5.1.6-11.el5           installed
>> php-soap.x86_64                          5.1.6-11.el5           installed
>> php-xml.x86_64                           5.1.6-11.el5           installed
>> php-xmlrpc.x86_64                        5.1.6-11.el5           installed
>>
>>
>>
>> WindowsXP System details:
>> **************************************************
>> PHP 5.2.1 (cli) (built: Feb  7 2007 23:11:26)
>> Copyright (c) 1997-2007 The PHP Group
>> Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
>>    with Zend Extension Manager v1.0.11, Copyright (c) 2003-2006, by Zend
>> Technologies
>>    with Zend Optimizer v3.2.2, Copyright (c) 1998-2006, by Zend
>> Technologies
>>
>> PCRE:
>> *************************************************
>> PCRE Library Version => 6.7 04-Jul-2006
>>
>>
>> Josh
>>
>>
>>
>>
>
>
>
>

[Joshua Ross]

Darby Felton <darby@...> writes:

>
> Hi Josh,
>
> The reason that it is failing for you appears to be that your PCRE does
> not have UTF-8 support compiled in. This is likely the result of the
> particular distribution not having used the --enable-utf8 option.
>
> What this means to us is that the class should become aware of whether
> such support is available, and act accordingly.
>
> I'll go ahead and file a JIRA issue for this so that users of
> distributions that do not have PCRE UTF-8 support may still use the
> affected classes (though of course without UTF-8 support :) ).
>
> Best regards,
> Darby
>

My newslist reader must be slow, I'm responding but it only posts about 30
minutes later.  I am not sure the UTF-8 issue is the problem here.  I just ran
this simple test script and received no error:


ini_set('display_errors', 'On');
error_reporting(E_ALL);

preg_match('/[^[\p{L}\p{N}]]/u', 'testing123', $matches);
var_dump($matches);

My assumption based on the link you posted is that an unsupported option such as
/u would have given me a php warning message.  I am looking for a way to
determine what options were used for the PCRE distribution... it is a RHEL5
package so I should be able to find it.

Josh

[Darby Felton]

Hi Josh,

It's already filed as:

http://framework.zend.com/issues/browse/ZF-1641

We can post further comments and results there for further investigation.

Best regards,
Darby

Joshua Ross wrote:

> I can file the bug report.
> I'll take a look at the link you posted here and report back as well,
> thanks!!
> Josh
>
>
> "Darby Felton" <[hidden email]> wrote in message
> news:[hidden email]...
>> Hi Josh,
>>
>> Maybe this helps you get UTF-8 support on your system?
>>
>> http://drupal.org/node/40961
>>
>> We should likely put detection of such support into the class in order
>> to prevent such problems from happening in the future. Would you mind
>> filing a bug report, or shall I do it for us?
>>
>> Best regards,
>> Darby
>>
>> Joshua Ross wrote:
>>> I posted this once in response to another post and then in my
>>> investigation
>>> I found that these validators have changed in 1.0RC3 somewhat
>>> dramatically.We are having problems using Zend_Validate_Alpha and
>>> Zend_Validate_Alnum but only on our production RHEL5 server.  Using xampp
>>> locally on windows XP the same code works perfectly.  Prior to 1.0RC3
>>> this
>>> worked on production as well.  We are running ZF 1.0RC3.  Here is the
>>> test
>>> code(similar to original post):
>>>
>>> $validator = new Zend_Validate_Alnum();
>>>
>>> $vars = array('Alnum' => 'foobar1',
>>>               'notAlnum' => 'foob@r1');
>>> foreach ($vars as $var) {
>>>         echo $validator->isValid($var) ? $var.":true\n":$var.":false\n";
>>> }
>>>
>>> RHEL5 response:
>>> foobar1:false
>>> foob@r1:false
>>>
>>> WindowsXP response:
>>> foobar1:true
>>> foob@r1:false
>>>
>>> Looking at the code both validators now leverage the filters instead of
>>> using ctype functions.  The filters use perl reg exp but even those have
>>> changed.
>>> For example, Zend_Validate_Alnum was:
>>> /[^[:alnum:]]/
>>>
>>> and now it is:
>>> /[^\p{L}\p{N}]/u
>>>
>>> minus the whitespace logic.  I assume the whitespace logic is why this
>>> was
>>> changed.  Testing the new expression using pcretest I am receiving false
>>> for
>>> valid strings.
>>>
>>> RHEL5 & Windows XP
>>> ******
>>>> pcretest
>>> PCRE version 6.6 06-Feb-2006
>>>
>>>   re> /[^\p{L}\p{N}]/u
>>> ** Unknown option 'u'
>>>   re> /[^\p{L}\p{N}]/
>>> data> foobar1
>>>  0: f
>>> data> foobar
>>>  0: f
>>> data> foobar@1
>>>  0: f
>>>
>>> I am quite confused!  Is the regular expression incorrect?  It appears
>>> correct based on my investigation but it is obviously not working. This
>>> failed on both windowsXP and the RHEL5 server, both of which are running
>>> pcretest 6.6.  It did, however, work in my test php script on Windows XP.
>>> The one difference here is that my PHP install on my Windows XP box has
>>> PCRE
>>> 6.7.  Is this reg exp only available in PCRE 6.7?
>>>
>>> I don't have a windows XP 6.7 pcretest at the moment, going to look to
>>> see
>>> if cygwin has it ready for download.  Once I test it I will post the
>>> results.  Below are some server details:
>>>
>>>
>>> RHEL 5 System details:
>>> ******************************************************
>>> PHP 5.1.6 (cli) (built: Apr  4 2007 11:38:24)
>>> Copyright (c) 1997-2006 The PHP Group
>>> Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
>>>     with Zend Extension Manager v1.2.0, Copyright (c) 2003-2006, by Zend
>>> Technologies
>>>     with Zend Optimizer v3.2.6, Copyright (c) 1998-2007, by Zend
>>> Technologies
>>>
>>> yum info:
>>> *******
>>> PCRE
>>> ---------------------------------------------------------------
>>> pcre.x86_64                              6.6-1.1                installed
>>>
>>> PHP
>>> ---------------------------------------------------------------
>>> php.x86_64                               5.1.6-11.el5           installed
>>> php-bcmath.x86_64                        5.1.6-11.el5           installed
>>> php-cli.x86_64                           5.1.6-11.el5           installed
>>> php-common.x86_64                        5.1.6-11.el5           installed
>>> php-dba.x86_64                           5.1.6-11.el5           installed
>>> php-devel.x86_64                         5.1.6-11.el5           installed
>>> php-gd.x86_64                            5.1.6-11.el5           installed
>>> php-imap.x86_64                          5.1.6-11.el5           installed
>>> php-ldap.x86_64                          5.1.6-11.el5           installed
>>> php-mbstring.x86_64                      5.1.6-11.el5           installed
>>> php-mysql.x86_64                         5.1.6-11.el5           installed
>>> php-ncurses.x86_64                       5.1.6-11.el5           installed
>>> php-odbc.x86_64                          5.1.6-11.el5           installed
>>> php-pdo.x86_64                           5.1.6-11.el5           installed
>>> php-pear.noarch                          1:1.4.9-4              installed
>>> php-pgsql.x86_64                         5.1.6-11.el5           installed
>>> php-snmp.x86_64                          5.1.6-11.el5           installed
>>> php-soap.x86_64                          5.1.6-11.el5           installed
>>> php-xml.x86_64                           5.1.6-11.el5           installed
>>> php-xmlrpc.x86_64                        5.1.6-11.el5           installed
>>>
>>>
>>>
>>> WindowsXP System details:
>>> **************************************************
>>> PHP 5.2.1 (cli) (built: Feb  7 2007 23:11:26)
>>> Copyright (c) 1997-2007 The PHP Group
>>> Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
>>>     with Zend Extension Manager v1.0.11, Copyright (c) 2003-2006, by Zend
>>> Technologies
>>>     with Zend Optimizer v3.2.2, Copyright (c) 1998-2006, by Zend
>>> Technologies
>>>
>>> PCRE:
>>> *************************************************
>>> PCRE Library Version => 6.7 04-Jul-2006
>>>
>>>
>>> Josh
>>>
>>>
>>>
>>>
>
>
>
>

[Graham Anderson]

On Wednesday 27 June 2007 18:38:07 Darby Felton wrote:

> Hi Josh,
>
> It's already filed as:
>
> http://framework.zend.com/issues/browse/ZF-1641
>
> We can post further comments and results there for further investigation.
>
> Best regards,
> Darby

Hiya,

I can't post to JIRA at the moment so this will have to do in the meantime.

From testing on my platforms ( openSUSE/SUSE-OSS 10.0, 10.1, 10.2 ), I have
the following results:

Up to ( but not including ) apache2-mod_php5-5.2.0-10.rpm testing against the
PCRE expression in current Zend_Filter_Alnum passes.

From mod_php5 version that ships with openSUSE 10.2 ( 5.2.0-10 ) to the
current available in the openSUSE build service, ( 5.2.3-29.1 ), testing
against the pattern fails.

On openSUSE mod_php5-5.2.0-10 and greater is built against the system PCRE
library and not the PHP bundled one, on opensuse 10.2 this is pcre-6.7-21.
While  patterns with UTF-8 options match against this system library outside
of PHP; they do not, for whatever reason match when used inside of PHP.

Workaround, on openSUSE 10.2 an upgrade of the system PCRE to the latest
available from the openSUSE build service ( pcre-7.1-16 ) will allow pattern
matching inside of PHP to function as expected.

Cheers
Graham

[Pádraic Brady]

Some javascript/style in this post has been disabled (why?)

JIRA is down at the moment...

I can confirm openSuse as a problem - I've been updated around the packaged versions for some time otherwise my own names gets a few squawks of protest ;). The level of compatility issues seems to indicate a problem with PHP integrating with PCRE in some distributions. Some of the problem issues still occur even if PCRE appears to be compiled with UTF-8 support (6.x at least).

Ubuntu seems perfectly fine. I compiled my own Fedora PHP so I don't know about it's packaged versions. My own work.

This problem isn't going to vanish anytime soon - there's very little the framework can do except shift down from Unicode against such issues. That causes another problem in how to manage the inconsistency so migrating/installing applications don't bork on the spot when using a simple accented character. It might be useful to distinguish between Alnum for ASCII/ISO and Alnum for Unicode/UTF-8 so a programmer can select which to use themselves.

Regards,
Paddy

 

Pádraic Brady
http://blog.astrumfutura.com
http://www.patternsforphp.com

----- Original Message ----
From: Graham Anderson <[hidden email]>
To: [hidden email]
Sent: Wednesday, June 27, 2007 11:05:16 PM
Subject: Re: [fw-general] Re: Zend_Validate_Alnum and Zend_Validate_Alpha failing(ZF1.0RC3)

On Wednesday 27 June 2007 18:38:07 Darby Felton wrote:

> Hi Josh,
>
> It's already filed as:
>
> http://framework.zend.com/issues/browse/ZF-1641
>
> We can post further comments and results there for further investigation.
>
> Best regards,
> Darby

Hiya,

I can't post to JIRA at the moment so this will have to do in the meantime.

From testing on my platforms ( openSUSE/SUSE-OSS 10.0, 10.1, 10.2 ), I have
the following results:

Up to ( but not including ) apache2-mod_php5-5.2.0-10.rpm testing against the
PCRE expression in current Zend_Filter_Alnum passes.

From mod_php5 version that ships with openSUSE 10.2 ( 5.2.0-10 ) to the
current available in the openSUSE build service, ( 5.2.3-29.1 ), testing
against the pattern fails.

On openSUSE mod_php5-5.2.0-10 and greater is built against the system PCRE
library and not the PHP bundled one, on opensuse 10.2 this is pcre-6.7-21.
While  patterns with UTF-8 options match against this system library outside
of PHP; they do not, for whatever reason match when used inside of PHP.

Workaround, on openSUSE 10.2 an upgrade of the system PCRE to the latest
available from the openSUSE build service ( pcre-7.1-16 ) will allow pattern
matching inside of PHP to function as expected.

Cheers
Graham

---

Need a vacation? Get great deals to amazing places on Yahoo! Travel.

[Andries Seutens]

Pádraic,

Please try my patched version attached.

Let me know if it works, please.

Best,


Andries Seutens
http://andries.systray.be

Pádraic Brady schreef:

> JIRA is down at the moment...
>
> I can confirm openSuse as a problem - I've been updated around the
> packaged versions for some time otherwise my own names gets a few
> squawks of protest ;). The level of compatility issues seems to
> indicate a problem with PHP integrating with PCRE in some
> distributions. Some of the problem issues still occur even if PCRE
> appears to be compiled with UTF-8 support (6.x at least).
>
> Ubuntu seems perfectly fine. I compiled my own Fedora PHP so I don't
> know about it's packaged versions. My own work.
>
> This problem isn't going to vanish anytime soon - there's very little
> the framework can do except shift down from Unicode against such
> issues. That causes another problem in how to manage the inconsistency
> so migrating/installing applications don't bork on the spot when using
> a simple accented character. It might be useful to distinguish between
> Alnum for ASCII/ISO and Alnum for Unicode/UTF-8 so a programmer can
> select which to use themselves.
>
> Regards,
> Paddy
>  
> Pádraic Brady
> http://blog.astrumfutura.com
> http://www.patternsforphp.com
>
>
> ----- Original Message ----
> From: Graham Anderson <[hidden email]>
> To: [hidden email]
> Sent: Wednesday, June 27, 2007 11:05:16 PM
> Subject: Re: [fw-general] Re: Zend_Validate_Alnum and
> Zend_Validate_Alpha failing(ZF1.0RC3)
>
> On Wednesday 27 June 2007 18:38:07 Darby Felton wrote:
> > Hi Josh,
> >
> > It's already filed as:
> >
> > http://framework.zend.com/issues/browse/ZF-1641
> >
> > We can post further comments and results there for further
> investigation.
> >
> > Best regards,
> > Darby
>
> Hiya,
>
> I can't post to JIRA at the moment so this will have to do in the
> meantime.
>
> >From testing on my platforms ( openSUSE/SUSE-OSS 10.0, 10.1, 10.2 ),
> I have
> the following results:
>
> Up to ( but not including ) apache2-mod_php5-5.2.0-10.rpm testing
> against the
> PCRE expression in current Zend_Filter_Alnum passes.
>
> From mod_php5 version that ships with openSUSE 10.2 ( 5.2.0-10 ) to the
> current available in the openSUSE build service, ( 5.2.3-29.1 ), testing
> against the pattern fails.
>
> On openSUSE mod_php5-5.2.0-10 and greater is built against the system
> PCRE
> library and not the PHP bundled one, on opensuse 10.2 this is
> pcre-6.7-21.
> While  patterns with UTF-8 options match against this system library
> outside
> of PHP; they do not, for whatever reason match when used inside of PHP.
>
> Workaround, on openSUSE 10.2 an upgrade of the system PCRE to the latest
> available from the openSUSE build service ( pcre-7.1-16 ) will allow
> pattern
> matching inside of PHP to function as expected.
>
> Cheers
> Graham
>
>
> ------------------------------------------------------------------------
> Need a vacation? Get great deals to amazing places
> <http://us.rd.yahoo.com/evt=48256/*http://travel.yahoo.com/;_ylc=X3oDMTFhN2hucjlpBF9TAzk3NDA3NTg5BHBvcwM1BHNlYwNncm91cHMEc2xrA2VtYWlsLW5jbQ-->on
> Yahoo! Travel.
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.476 / Virus Database: 269.9.10/875 - Release Date: 27/06/2007 21:08
>  

--
Andries Seutens
http://andries.systray.be



Gecontroleerd op virussen door de JOJO Secure Gateway.

[Andries Seutens]

One note with this patch.... of course UTF-8 supports get's dropped when
PCRE isn't compiled with UTF-8 and Unicode stuff support.

Best,

Andries Seutens
http://andries.systray.be

Andries Seutens schreef:

> Pádraic,
>
> Please try my patched version attached.
>
> Let me know if it works, please.
>
> Best,
>
>
> Andries Seutens
> http://andries.systray.be
>
> Pádraic Brady schreef:
>> JIRA is down at the moment...
>>
>> I can confirm openSuse as a problem - I've been updated around the
>> packaged versions for some time otherwise my own names gets a few
>> squawks of protest ;). The level of compatility issues seems to
>> indicate a problem with PHP integrating with PCRE in some
>> distributions. Some of the problem issues still occur even if PCRE
>> appears to be compiled with UTF-8 support (6.x at least).
>>
>> Ubuntu seems perfectly fine. I compiled my own Fedora PHP so I don't
>> know about it's packaged versions. My own work.
>>
>> This problem isn't going to vanish anytime soon - there's very little
>> the framework can do except shift down from Unicode against such
>> issues. That causes another problem in how to manage the
>> inconsistency so migrating/installing applications don't bork on the
>> spot when using a simple accented character. It might be useful to
>> distinguish between Alnum for ASCII/ISO and Alnum for Unicode/UTF-8
>> so a programmer can select which to use themselves.
>>
>> Regards,
>> Paddy
>>  
>> Pádraic Brady
>> http://blog.astrumfutura.com
>> http://www.patternsforphp.com
>>
>>
>> ----- Original Message ----
>> From: Graham Anderson <[hidden email]>
>> To: [hidden email]
>> Sent: Wednesday, June 27, 2007 11:05:16 PM
>> Subject: Re: [fw-general] Re: Zend_Validate_Alnum and
>> Zend_Validate_Alpha failing(ZF1.0RC3)
>>
>> On Wednesday 27 June 2007 18:38:07 Darby Felton wrote:
>> > Hi Josh,
>> >
>> > It's already filed as:
>> >
>> > http://framework.zend.com/issues/browse/ZF-1641
>> >
>> > We can post further comments and results there for further
>> investigation.
>> >
>> > Best regards,
>> > Darby
>>
>> Hiya,
>>
>> I can't post to JIRA at the moment so this will have to do in the
>> meantime.
>>
>> >From testing on my platforms ( openSUSE/SUSE-OSS 10.0, 10.1, 10.2 ),
>> I have
>> the following results:
>>
>> Up to ( but not including ) apache2-mod_php5-5.2.0-10.rpm testing
>> against the
>> PCRE expression in current Zend_Filter_Alnum passes.
>>
>> From mod_php5 version that ships with openSUSE 10.2 ( 5.2.0-10 ) to the
>> current available in the openSUSE build service, ( 5.2.3-29.1 ), testing
>> against the pattern fails.
>>
>> On openSUSE mod_php5-5.2.0-10 and greater is built against the system
>> PCRE
>> library and not the PHP bundled one, on opensuse 10.2 this is
>> pcre-6.7-21.
>> While  patterns with UTF-8 options match against this system library
>> outside
>> of PHP; they do not, for whatever reason match when used inside of PHP.
>>
>> Workaround, on openSUSE 10.2 an upgrade of the system PCRE to the latest
>> available from the openSUSE build service ( pcre-7.1-16 ) will allow
>> pattern
>> matching inside of PHP to function as expected.
>>
>> Cheers
>> Graham
>>
>>
>> ------------------------------------------------------------------------
>> Need a vacation? Get great deals to amazing places
>> <http://us.rd.yahoo.com/evt=48256/*http://travel.yahoo.com/;_ylc=X3oDMTFhN2hucjlpBF9TAzk3NDA3NTg5BHBvcwM1BHNlYwNncm91cHMEc2xrA2VtYWlsLW5jbQ-->on
>> Yahoo! Travel.
>> ------------------------------------------------------------------------
>>
>> No virus found in this incoming message.
>> Checked by AVG Free Edition. Version: 7.5.476 / Virus Database:
>> 269.9.10/875 - Release Date: 27/06/2007 21:08
>>  
>
>
> ------------------------------------------------------------------------
>
> Gecontroleerd op virussen door de JOJO Secure Gateway.
>  
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.476 / Virus Database: 269.9.10/875 - Release Date: 27/06/2007 21:08
>  

--
Andries Seutens
http://andries.systray.be


Gecontroleerd op virussen door de JOJO Secure Gateway.