Jason Wong wrote:
On Thursday 25 November 2004 17:43, Olaf van der Spek wrote:
I'm more worried about the data (in MySQL), not the code.
By protecting the MySQL password from being read by scripts directly and
only allowing access based on the current vhost, only this vhost can
access it&
Raditha Dissanayake wrote:
Olaf van der Spek wrote:
Hi,
Is there a way to store MySQL (or other sensitive data) that will be
It should read MySQL passwords.
passed to a library in such a way that scripts itself can't access this?
A per-vhost store would be ideal.
If not, would this be a good
Hi,
Is there a way to store MySQL (or other sensitive data) that will be
passed to a library in such a way that scripts itself can't access this?
A per-vhost store would be ideal.
If not, would this be a good idea to implement?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, vis
John Nichel wrote:
Olaf van der Spek wrote:
Isn't that only an issue for < 4.1 clients and >= 4.1 servers and not
for the 'other way around'?
I was actually asking because I have a 4.1 server and I couldn't use
PHP to connect, because it doesn't support new passw
John Nichel wrote:
Olaf van der Spek wrote:
But why is the bundled client not upgraded?
Aren't 4.0 and 4.1 clients backwards compatible with 3.23 server?
Why they didn't upgrade the bundle to include the 4.0 release, I don't
know. However with the password 'issues'
John Nichel wrote:
Steve Buehler wrote:
My phpinfo client API shows: 3.23.58
Which would be because that is the version of mysql that I am
running. My mysql, mysql-server and mysql-devel are all 3.23.58.
Only my php-mysql module is 4.3.2-14
No, this is not the case. If you install with RPM, o
On Wed, 24 Nov 2004 10:37:19 -0600, Steve Buehler <[EMAIL PROTECTED]> wrote:
> At 07:38 AM 11/24/2004, you wrote:
>
> >In the phpinfo() output, the MySQL client API version is shown as 3.23.49.
> >Shouldn't this be upgraded to 4.1 (generally available/stable)?
>
> To do so, you would need to upgr
In the phpinfo() output, the MySQL client API version is shown as 3.23.49.
Shouldn't this be upgraded to 4.1 (generally available/stable)?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Mike Ford wrote:
for. (Some early business-oriented computers, and some calculators
(especially financial ones) did use a system called binary-coded
decimal -- BCD -- to calculate "accurately" in the sense you mean,
but the fact that they were never widely used and have died out
almost totally sho
Chris Shiflett wrote:
--- Olaf van der Spek <[EMAIL PROTECTED]> wrote:
Since which version does PHP require the Content-Type header in
POST requests?
Content-Type is required for any request that has content. It's an HTTP
The RFC says should, not is required to.
Any HTTP/1.1 message co
Chris Shiflett wrote:
--- Olaf van der Spek <[EMAIL PROTECTED]> wrote:
Content-Type is required for any request that has content.
It's an HTTP requirement and has very little to do with PHP.
Can you explain what you're talking about?
I was talking about the request, not about the r
Chris Shiflett wrote:
--- Olaf van der Spek <[EMAIL PROTECTED]> wrote:
Since which version does PHP require the Content-Type header in
POST requests?
Content-Type is required for any request that has content. It's an HTTP
requirement and has very little to do with PHP.
Can you explain
Hi,
Since which version does PHP require the Content-Type header in POST
requests?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Manuel Lemos wrote:
Hello,
On 10/03/2004 01:46 PM, Olaf Van Der Spek wrote:
Why?
I think a large number of data handling functions would benefit from
such a function.
And it'd make PHP more robust.
Because it is an hack to work around the lack of support for detection
of corrupted data in
David Bevan wrote:
On October 3, 2004 12:46, Olaf van der Spek wrote:
Manuel Lemos wrote:
Hello,
On 10/03/2004 12:27 PM, Olaf Van Der Spek wrote:
I think that making all failed memory allocations recoverable is not
viable because more PHP C code that makes memory allocations assumes
it only
Manuel Lemos wrote:
Hello,
On 10/03/2004 12:27 PM, Olaf Van Der Spek wrote:
I think that making all failed memory allocations recoverable is not
viable because more PHP C code that makes memory allocations assumes
it only returns if it succeeds. Trying to change that everywhere
memory is
Manuel Lemos wrote:
Hello,
I think that making all failed memory allocations recoverable is not
viable because more PHP C code that makes memory allocations assumes it
only returns if it succeeds. Trying to change that everywhere memory is
allocated is and monster job that I doubt that any PHP c
Manuel Lemos wrote:
Hello,
On 10/02/2004 06:01 PM, Olaf Van Der Spek wrote:
AFAIK PHP runs safely in multi-threaded servers. What you can't
expect is that PHP handles abnormal situations caused by flaws in the
external libraries that PHP links with.
When I link with the same library in a
Manuel Lemos wrote:
AFAIK PHP runs safely in multi-threaded servers. What you can't expect
is that PHP handles abnormal situations caused by flaws in the external
libraries that PHP links with.
When I link with the same library in a C app, this 'abnormal situation'
just results in a normal retur
Manuel Lemos wrote:
If you do not think that discussing your alternative solution is worth
doing in php-dev, I do not think that keep discussing it php-general is
helping anybody.
I will post there.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.
Manuel Lemos wrote:
Hello,
On 10/01/2004 11:20 AM, Olaf Van Der Spek wrote:
I was not aware that memory allocation failures could make PHP to
exit its process but since it seems intentional there must be a
reasoning behind that for which I am not the person that should
explain. Maybe the reason
Manuel Lemos wrote:
Hello,
On 10/01/2004 11:34 AM, Olaf Van Der Spek wrote:
If it is not normal, why don't you just evaluate the expected memory
size that is going to be allocated before calling the PHP function
that does it and handle the situation within your PHP code?
Because I'
Manuel Lemos wrote:
If it is not normal, why don't you just evaluate the expected memory
size that is going to be allocated before calling the PHP function that
does it and handle the situation within your PHP code?
Because I've no idea how gzinflate decides how much memory to allocate.
--
PHP Ge
Manuel Lemos wrote:
I was not aware that memory allocation failures could make PHP to exit
its process but since it seems intentional there must be a reasoning
behind that for which I am not the person that should explain. Maybe the
reason has to due to the fact that when memory allocation fails
Manuel Lemos wrote:
Hello,
On 10/01/2004 10:32 AM, Olaf Van Der Spek wrote:
That is not a crash. Your script making a PHP function request 600MB
of memory. Since it exceeds the configured memory limit, there is no
way to recover from memory exhaustion and the script just exits
cleanly. It
BTW
Manuel Lemos wrote:
On 10/01/2004 10:29 AM, Olaf Van Der Spek wrote:
So Apache restarts just because it thinks that's funny?
FATAL: erealloc(): Unable to allocate 603602944 bytes
[Sun Sep 19 16:11:16 2004] [notice] Parent: child process exited with
status 1 -- Restarting.
I was not aware
Manuel Lemos wrote:
That is not a crash. Your script making a PHP function request 600MB of
memory. Since it exceeds the configured memory limit, there is no way to
recover from memory exhaustion and the script just exits cleanly. It
BTW, I don't agree. It's easily possible to recover from this
Manuel Lemos wrote:
Hello,
On 10/01/2004 10:12 AM, Olaf Van Der Spek wrote:
So what went wrong with this bug report?
http://bugs.php.net/bug.php?id=30153
It's marked as bogus, although it provides a script to reproduce the
crash.
That is not a crash. Your script making a PHP function re
Manuel Lemos wrote:
Hello,
On 10/01/2004 10:00 AM, Olaf Van Der Spek wrote:
Is a (bug in a) script allowed to cause such a crash?
Not bugs in a script but rather in the PHP engine. In theory, the PHP
engine should never crash but there is no such thing as bug free
software.
So if I report a
Manuel Lemos wrote:
Hello,
On 10/01/2004 09:41 AM, Olaf Van Der Spek wrote:
What is the PHP policy regaring crashes and fatal errors?
Are scripts allowed to cause a crash or fatal error of Apache/PHP
itself?
A PHP served request can only crash if there is a bug that makes it
crash.
Sure. But
Manuel Lemos wrote:
Hello,
On 10/01/2004 08:54 AM, Olaf Van Der Spek wrote:
What is the PHP policy regaring crashes and fatal errors?
Are scripts allowed to cause a crash or fatal error of Apache/PHP itself?
A PHP served request can only crash if there is a bug that makes it crash.
Sure. But what
Hi,
What is the PHP policy regaring crashes and fatal errors?
Are scripts allowed to cause a crash or fatal error of Apache/PHP itself?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
32 matches
Mail list logo
