Hi to all. I'm having problems with the Blowfish encryption method. It's
not a PHP problem, because what i get encrypted with the lybrary, i can
decrypt it later. The problem became when i encrypt a text with another
Blowfish library and try to get decrypted with the PHP's library,
because i
At 06:44 18-12-2002, Moriyoshi Koizumi wrote:
Andi Gutmans [EMAIL PROTECTED] wrote:
At 12:49 AM 12/17/2002 +0900, Moriyoshi Koizumi wrote:
Andi Gutmans [EMAIL PROTECTED] wrote:
I don't understand what you're doing here. Are you actually
separating on
every assignment and doing a deep
On Wed, 18 Dec 2002, victor wrote:
Hi to all. I'm having problems with the Blowfish encryption method. It's
not a PHP problem, because what i get encrypted with the lybrary, i can
decrypt it later. The problem became when i encrypt a text with another
Blowfish library and try to get
Derick Rethans wrote:
On Wed, 18 Dec 2002, victor wrote:
Hi to all. I'm having problems with the Blowfish encryption method. It's
not a PHP problem, because what i get encrypted with the lybrary, i can
decrypt it later. The problem became when i encrypt a text with another
Blowfish library
Hello,
can some developer on windows please fix the following tests:
regards,
Derick
E:\devel\php4\ext\standard\tests\file\001.phpt
At 12:38 18.12.2002, Derick Rethans wrote:
Hello,
can some developer on windows please fix the following tests:
regards,
Derick
E:\devel\php4\ext\standard\tests\file\001.phpt
I've installed the newest version of PHP on an ISS 5.0 based System.
The problem I have at the moment:
If post a variable (URL Query) e.g.: xxx.php?errormsg=error message to a
site, php is unable to get these variable. On my linux server the space is
interpreted as %20 in the correct way.
On IIS
At 13:19 18-12-02 +0100, Michael A. Norweh wrote:
I've installed the newest version of PHP on an ISS 5.0 based System.
The problem I have at the moment:
If post a variable (URL Query) e.g.: xxx.php?errormsg=error message to a
site, php is unable to get these variable. On my linux server the space
Hi!
some time ago (half year or so) I submited this bug ...
I cleaned the patch (at last ;)) - it is in attached file.
It applies to php-4.2.3 and also to php-4.3.0RC3 (with offset warnings
but works ok).
Please someone add it to main version or give me CVS account so I could
do it by myself.
Does anyone know of a way to retrieve MS Outlook data via PHP? I am creating
an intrant for my company and want to grab data from the MS Oulook contact
list on the server to using in my PHP/MySQL intranet project.
Any help would be most appreciated.
Thank you!
Chris Streeter
Bethlehem, PA USA
You should be able to use LDAP if you have an Exchange server.
Marco
--
php|architect - The Magazine for PHP Professionals
The monthly magazine dedicated to the world of PHP programming
Check us out on the web at http://www.phparch.com!
---BeginMessage---
Does anyone know of a
On Tue, 17 Dec 2002, Chris Streeter wrote:
Does anyone know of a way to retrieve MS Outlook data via PHP? I am creating
an intrant for my company and want to grab data from the MS Oulook contact
list on the server to using in my PHP/MySQL intranet project.
Please ask user questions on the PHP
Hi,
I'm trying to provide samples for authenticating using MS-CHAP and my
Radius PECL.
I need DES for generating the data., but it seems that des is only
available via mcrypt-extension, but mcrypt only compiles under unix or
am i wrong?
Its nearly useless to provide a sample for MS-CHAP only
Check out the Mcrypt manual page:
http://us2.php.net/mcrypt
In the comments several people posted links to DLL (windows) version's of
the MCRYPT library.
On Wed, 2002-12-18 at 10:40, Michael Bretterklieber wrote:
Hi,
I'm trying to provide samples for
On 18 Dec 2002, Adam Voigt wrote:
Check out the Mcrypt manual page:
http://us2.php.net/mcrypt
In the comments several people posted links to DLL (windows) version's
of
the MCRYPT library.
The main problems with the library where the dynamic loading of the
ciphers. In mcrypt version
It would be a welcome addition but wouldn't this create legal
problems with the U.S. export laws in-reference to high powered
encryption technology/software?
On Wed, 2002-12-18 at 11:11, Derick Rethans wrote:
On 18 Dec 2002, Adam Voigt wrote:
Check out the
Melvyn Sopacua [EMAIL PROTECTED] wrote:
--snip
OK so that's a deep copy. As much as I understand the motivation I don't
think this should be done. It'll slow down lots of things in PHP. I think
this should be solved by documentation.
Yes, according to my trivial benchmark, my patch
On 18 Dec 2002, Adam Voigt wrote:
It would be a welcome addition but wouldn't this create legal
problems with the U.S. export laws in-reference to high powered
encryption technology/software?
We're not exporting the encryptions as we will not distribute the
library, but I'm sure we'll find a
Hi,
Derick Rethans wrote:
On 18 Dec 2002, Adam Voigt wrote:
Check out the Mcrypt manual page:
http://us2.php.net/mcrypt
In the comments several people posted links to DLL (windows) version's
of
the MCRYPT library.
The main problems with the library where the dynamic loading of the
Hi,
Derick Rethans wrote:
On 18 Dec 2002, Adam Voigt wrote:
It would be a welcome addition but wouldn't this create legal
problems with the U.S. export laws in-reference to high powered
encryption technology/software?
Wasn't his law dropped or weaked some years ago?
I can imaging if you
Not to plug my own wares or anything, but you might want to look at
cryptopp-php, which works on both UNIX and Windows. See
http://www.tutorbuddy.com/software/
It works fine on both platforms and is compatible both ways -- ciphertext
created on one platform can be decrypted on another and
All,
I've looked at the list of CVS commits over the last few days and saw
that people are committing apparently non-critical things to the branch.
Please do not do that! After the final RC only fixes for crash and
showstopper bugs should be merged in. Those of you doing it are only
slowing down
On Mon, Dec 16, 2002 at 03:27:45PM +, Patrick Welche wrote:
I just tried the cvs source, and essentially get stuck compiling it because
zend_globals_macros.h needs ZEND_API to be defined. This is defined in
Zend/acconfig.h. acconfig.h is only inclued if defined NETWARE.
Now, I tried to
What was the consensus on CGI vs. CLI naming or merging issue? Or was
there a consensus at all? I full plan to go ahead with 4.3.0 release
before the end of the year, so those interested in doing anything about
this issue better get their butts in gear.
-Andrei
At 11:17 AM 12/17/2002 +0900, Moriyoshi Koizumi wrote:
Andi Gutmans [EMAIL PROTECTED] wrote:
I didn't understand the explanation. Why do you mind if the resources are
destroyed before the constants? That's good, no?
Sorry, I'm still unsure if my patch is the correct one, as I said in the
This note from Derick pretty much reflects the idea... it makes sense:
quote
I see that renaming the CGI to php-cgi might break things indeed, and
that's never a good idea. But so is changing the name of the CLI (php)
to something else. It also breaks things, not only for me, but also for
This note from Derick pretty much reflects the idea... it makes sense:
quote
I see that renaming the CGI to php-cgi might break things indeed, and
that's never a good idea. But so is changing the name of the CLI (php)
to something else. It also breaks things, not only for me, but also for
The problems that can occur that I can think of are:
- Crontabs calling the php CLI binary
- CLI scripts starting with #!/usr/bin/php
- Scripts from other languages calling for a specific binary
- and also all the users that call the CLI binary directly by its name.
I agree that the old binary
Hi
Andrei Zmievski wrote:
What was the consensus on CGI vs. CLI naming or merging issue? Or was
there a consensus at all? I full plan to go ahead with 4.3.0 release
before the end of the year, so those interested in doing anything
about this issue better get their butts in gear.
-Andrei
-Original Message-
From: Sterling Hughes [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, December 18, 2002 9:30 PM
To: Xavier Spriet
Cc: Andrei Zmievski; PHP Developers
Subject: Re: [PHP-DEV] CGI and CLI
This note from Derick pretty much reflects the idea... it makes sense:
quote
-Original Message-
From: Christoph Grottolo [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, December 18, 2002 9:39 PM
To: [EMAIL PROTECTED]
Subject: [PHP-DEV] Re: CGI and CLI
Hi
Andrei Zmievski wrote:
What was the consensus on CGI vs. CLI naming or merging issue? Or was
there a
On Wed, 18 Dec 2002, Sebastian Nohn wrote:
-Original Message-
From: Sterling Hughes [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, December 18, 2002 9:30 PM
To: Xavier Spriet
Cc: Andrei Zmievski; PHP Developers
Subject: Re: [PHP-DEV] CGI and CLI
This note from Derick
Experimental or not, people use it and have developed a need for it.
Many apps out there are based on experimental technology, that's not a
reason to break them all...
On Wed, 2002-12-18 at 15:48, Sebastian Nohn wrote:
-Original Message-
From: Sterling Hughes [mailto:[EMAIL
On Wed, 18 Dec 2002, Xavier Spriet wrote:
Experimental or not, people use it and have developed a need for it.
Many apps out there are based on experimental technology, that's not a
reason to break them all...
So I strongly suggest that whoever has the necessary knowledge on how to
merge CGI
At 03:54 PM 12/18/2002 -0500, Andrei Zmievski wrote:
On Wed, 18 Dec 2002, Xavier Spriet wrote:
Experimental or not, people use it and have developed a need for it.
Many apps out there are based on experimental technology, that's not a
reason to break them all...
So I strongly suggest that
On Wed, 18 Dec 2002, Andi Gutmans wrote:
At 03:54 PM 12/18/2002 -0500, Andrei Zmievski wrote:
On Wed, 18 Dec 2002, Xavier Spriet wrote:
Experimental or not, people use it and have developed a need for it.
Many apps out there are based on experimental technology, that's not a
reason to
-Original Message-
From: Derick Rethans [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, December 18, 2002 9:50 PM
To: Sebastian Nohn
Cc: PHP Developers
Subject: RE: [PHP-DEV] CGI and CLI
On Wed, 18 Dec 2002, Sebastian Nohn wrote:
-Original Message-
From: Sterling Hughes
If it gets done that way it will be really confusing for everyone...
All users used to CLI as php will need to switch to php-cli for
4.3.0 then back to php afterwards ?
I think if there's not enough time to merge both back together, it would
be wiser to wait a bit, at least until it's done if it
I think a lot more users will be pissed of when renaming php to php-cgi than
regarding to the cli-version of php as php-cli or phpsh or anything else.
The best solution would be indeed bundling both to one binary. If this
delays a 4.3.0-release? I don't give a damn about it! The idea release
On Wed, 18 Dec 2002, Sebastian Nohn wrote:
On Wed, 18 Dec 2002, Sebastian Nohn wrote:
This note from Derick pretty much reflects the idea... it
makes sense:
quote
I see that renaming the CGI to php-cgi might break things
indeed, and that's never a good idea. But so is
Again: Thousands if not millions of servers use PHP as CGI. Who uses PHP for
CLI-apps? 100? 1000? 5000? If you use experimental technology you always
MUST have in mind that anything can change anytime. Why was'nt PHP available
for Apache 2 for a long time (is it in the meantime btw.?)?. Because
-Original Message-
From: Andi Gutmans [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, December 18, 2002 10:03 PM
To: Andrei Zmievski; Xavier Spriet
Cc: Sebastian Nohn; Sterling Hughes; PHP Developers
Subject: Re: [PHP-DEV] CGI and CLI
At 03:54 PM 12/18/2002 -0500, Andrei Zmievski
-Original Message-
From: Derick Rethans [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, December 18, 2002 10:05 PM
To: Andi Gutmans
Cc: PHP Developers
Subject: Re: [PHP-DEV] CGI and CLI
On Wed, 18 Dec 2002, Andi Gutmans wrote:
At 03:54 PM 12/18/2002 -0500, Andrei Zmievski wrote:
On Wed, 18 Dec 2002, Sebastian Nohn wrote:
-Original Message-
From: Derick Rethans [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, December 18, 2002 10:05 PM
To: Andi Gutmans
Cc: PHP Developers
Subject: Re: [PHP-DEV] CGI and CLI
On Wed, 18 Dec 2002, Andi Gutmans wrote:
-Original Message-
From: Derick Rethans [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, December 18, 2002 10:14 PM
To: Sebastian Nohn
Cc: PHP Developers
Subject: RE: [PHP-DEV] CGI and CLI
On Wed, 18 Dec 2002, Sebastian Nohn wrote:
On Wed, 18 Dec 2002, Sebastian Nohn wrote:
On Wed, 2002-12-18 at 16:17, Sebastian Nohn wrote:
Again: Thousands if not millions of servers use PHP as CGI.
PHP-CGI will _NOT_ be renamed either.
Who uses PHP for
CLI-apps? 100? 1000? 5000? If you use experimental technology you always
MUST have in mind that anything can change
-Original Message-
From: Derick Rethans [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, December 18, 2002 10:20 PM
To: Sebastian Nohn
Cc: Andi Gutmans; PHP Developers
Subject: RE: [PHP-DEV] CGI and CLI
On Wed, 18 Dec 2002, Sebastian Nohn wrote:
-Original Message-
On Wed, 18 Dec 2002, Sebastian Nohn wrote:
But renaming php-cli to php means renaming php to anything else (php-cgi,
cgi-php, phpcgi, phpfoo, whatever), right?
No, we didn't do that for 4.2.[0-3] either:
[root@saturnus php-4.2.1]# ./configure --enable-cli
[root@saturnus php-4.2.1]# make
CGI:
On Wed, 18 Dec 2002, Derick Rethans wrote:
[...]
I didn't say that it should be changed from php to php-cgi, as I do
think that would be bad.
Derick
Why don't you just add a simple check in the CLI code to exec() the CGI
binary if it is called as a CGI?
if(getenv(GATEWAY_INTERFACE) != NULL)
-Original Message-
From: Xavier Spriet [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, December 18, 2002 10:25 PM
To: Sebastian Nohn
Cc: Sterling Hughes; Andrei Zmievski; PHP Developers
Subject: RE: [PHP-DEV] CGI and CLI
On Wed, 2002-12-18 at 16:17, Sebastian Nohn wrote:
Again:
On Wed, 18 Dec 2002, Sebastian Nohn wrote:
I think a lot more users will be pissed of when renaming php to php-cgi than
regarding to the cli-version of php as php-cli or phpsh or anything else.
The best solution would be indeed bundling both to one binary. If this
delays a 4.3.0-release? I
On Wed, 18 Dec 2002, Andrei Zmievski wrote:
On Wed, 18 Dec 2002, Sebastian Nohn wrote:
I think a lot more users will be pissed of when renaming php to php-cgi than
regarding to the cli-version of php as php-cli or phpsh or anything else.
The best solution would be indeed bundling both to
Robin Thellend wrote:
On Wed, 18 Dec 2002, Derick Rethans wrote:
[...]
I didn't say that it should be changed from php to php-cgi, as I do
think that would be bad.
Derick
Why don't you just add a simple check in the CLI code to exec() the CGI
binary if it is called as a CGI?
Derick Rethans wrote:
On Wed, 18 Dec 2002, Sebastian Nohn wrote:
But renaming php-cli to php means renaming php to anything else
(php-cgi, cgi-php, phpcgi, phpfoo, whatever), right?
No, we didn't do that for 4.2.[0-3] either:
[root@saturnus php-4.2.1]# ./configure --enable-cli
I'm with Shane, that sounds like a really poor idea.
On Wednesday, December 18, 2002, at 04:38 PM, Shane Caraveo wrote:
Robin Thellend wrote:
On Wed, 18 Dec 2002, Derick Rethans wrote:
[...]
I didn't say that it should be changed from php to php-cgi, as I do
think that would be bad.
Derick
On Wed, 18 Dec 2002, Sascha Schumann wrote:
The next point release after 4.2.0 was 4.2.1.
There are too many major changes in 4.3 vs. 4.2 to call it a
'point release'.
Semantics.
Especially, there are still significant
backwards compatibility bugs, such as
Plain and simple, and it is the ONLY way that 4.3 can be released.
There is no way in hell I would support the release of PHP with the cli
binary replacing the cgi binary. Change it back to the way it was in
4.2.x since there is no time to properly fix the problem. Leave it
marked
On Wed, 18 Dec 2002, Andi Gutmans wrote:
I doubt this will happen fast enough. We should just release the way we
released 4.2.x, which as far as I know was php for CGI and php-cli for CLI
or am I a bit behind things? :)
Derick and I hashed it out on IRC and we have a proposal:
We should
I would agree that this is a big problem.
Shane
Andrei Zmievski wrote:
On Wed, 18 Dec 2002, Sascha Schumann wrote:
The next point release after 4.2.0 was 4.2.1.
There are too many major changes in 4.3 vs. 4.2 to call it a
'point release'.
Semantics.
Especially, there are
Andrei Zmievski wrote:
On Wed, 18 Dec 2002, Andi Gutmans wrote:
I doubt this will happen fast enough. We should just release the way we
released 4.2.x, which as far as I know was php for CGI and php-cli for CLI
or am I a bit behind things? :)
Derick and I hashed it out on IRC and we have a
So every tutorial and documentation on this would have to
say this right?
Ask your sysadmin what the CGI and CLI versions of your
PHP are called, they could be anything as there is no
standard. For the purpose of this (tutorial|documentation),
we'll call CLI php-cli and CGI php-cgi.
On Wed, 18 Dec 2002, Philip Olson wrote:
So every tutorial and documentation on this would have to
say this right?
Ask your sysadmin what the CGI and CLI versions of your
PHP are called, they could be anything as there is no
standard. For the purpose of this
Great.
In that case, in order to make things a little smoother for users, could
a little workaround like the one offered by Robin be considered ?
On Wed, 2002-12-18 at 17:21, Andrei Zmievski wrote:
On Wed, 18 Dec 2002, Philip Olson wrote:
So every tutorial and documentation on this would
No. At the most, if anything, CLI should output an error message:
if(getenv(GATEWAY_INTERFACE) != NULL) {
printf(This is the PHP CLI binary, please configure your server to
use the correct PHP CGI binary.);
exit(1);
}
Xavier Spriet wrote:
Great.
In that case, in order to make things a
Looks good enough for me, I don't see a problem with that.
On Wed, 2002-12-18 at 17:39, Shane Caraveo wrote:
No. At the most, if anything, CLI should output an error message:
if(getenv(GATEWAY_INTERFACE) != NULL) {
printf(This is the PHP CLI binary, please configure your server to
use
The merging of CLI and CGI will still happen, but in 4.3.1.
I was not under the impression that this decision has been reached. In fact
there were several people strongly opposed to the idea and I'm one of them.
I have several reasons one of them being that having an interpreter which
Andrei Zmievski wrote:
On Wed, 18 Dec 2002, Andi Gutmans wrote:
I doubt this will happen fast enough. We should just release the way we
released 4.2.x, which as far as I know was php for CGI and php-cli for
CLI
or am I a bit behind things? :)
Derick and I hashed it out on IRC and we
Hey,
Just clarifying: We never agreed that -+[01] meant anything except a short
way of:
-1 = I strongly disagree
-0 = I disagree
0 = neutral
+0 = I agree
+1 = I strongly agree
ie, We don't have a voting system. If someone, let's call him Barney, says
-1 on this issue, all that means is that
I had discussed the issue with Rasmus and Jani some time ago and the
concensus reached was only to disable PHP_AUTH_USER when safe mode is
active. Nobody got around to do anything about it though. Is this still an
acceptable solution?
Edin
- Original Message -
From: Phil Driscoll [EMAIL
Edin Kadribasic wrote:
* On other platforms, the cgi *is* installed by 'make install' by
default. To install cli something like, 'make install-cli', or
'configure --install-cli=[DIR] --install-cgi=[DIR]' can be used (the
second option would be more usefull for installing both, using both
Sorry, I'm still unsure if my patch is the correct one, as I said in the
first mail. As far as I've looked into it, the streams seem to be
destructed and freed twice, once in deactivation and once in shutdown.
If you think my patch is bogus, feel free to revert it unless I can give
more
Well it's up to whoever has karma to make that decision.
People can give their opinion obviously but shouldn't expect to actually
make the decision.
On Wed, 2002-12-18 at 18:43, Sterling Hughes wrote:
Hey,
Just clarifying: We never agreed that -+[01] meant anything except a short
way of:
On Wed, 18 Dec 2002, Shane Caraveo wrote:
Edin Kadribasic wrote:
[snip]
I really don't understand why insist on cgi being installed on make
install to ${PREFIX}/bin? The solution outlined by Andrei and Derick is
much better IMHO because it will alert users of the issue and because
On 18 Dec 2002, Xavier Spriet wrote:
Well it's up to whoever has karma to make that decision.
People can give their opinion obviously but shouldn't expect to actually
make the decision.
That's the problem with the current state of PHP development.
Too many people think that their
Cutting down on the list of receipients here...
Philip please do not put this paragraph into the documentation. If
there is any sure fire way to ensure that the latest version of PHP
WON'T be installed on a system... it's to encourage end users to
contact their system administrator.
Although
I want to translate PHP manual to portuguese language, please, let me do this : ).
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
On Wed, 18 Dec 2002, Dan Kalowsky wrote:
Cutting down on the list of receipients here...
Philip please do not put this paragraph into the documentation. If
there is any sure fire way to ensure that the latest version of PHP
WON'T be installed on a system... it's to encourage end users to
At 12:56 AM 12/19/2002 +0100, Edin Kadribasic wrote:
Sorry, I'm still unsure if my patch is the correct one, as I said in the
first mail. As far as I've looked into it, the streams seem to be
destructed and freed twice, once in deactivation and once in shutdown.
If you think my patch is
On Wed, 18 Dec 2002, Shane Caraveo wrote:
Andrei Zmievski wrote:
Derick and I hashed it out on IRC and we have a proposal:
We should keep 4.2.x behavior with some modifications. CLI and CGI
should always be built unless disabled, and the executables should go
into sapi/cli/php and
On 18 Dec 2002, Xavier Spriet wrote:
Great.
In that case, in order to make things a little smoother for users, could
a little workaround like the one offered by Robin be considered ?
No, as that is a very ugly thing to do IMO.
Derick
--
On Wed, 18 Dec 2002, Shane Caraveo wrote:
No. At the most, if anything, CLI should output an error message:
if(getenv(GATEWAY_INTERFACE) != NULL) {
printf(This is the PHP CLI binary, please configure your server to
use the correct PHP CGI binary.);
exit(1);
}
Don't forget the
sorry about the false alarm , if you go here u will see a working example
http://galleries.dyndns.org:1023/progress.php
i had to add both flush functions together to work , obviosuly flsuh is not
emptying the buffer within a loop, is this still a bug ?
flush();
ob_flush();
Electroteque [EMAIL
82 matches
Mail list logo
