[PHP-DEV] variables_order annoyance

Guys, I think this was brought up before, and I somehow had the impression that we fixed it, but we didn't. Currently if variables_order does not contain a certain type then that type will not be populated in the $_FOO superglobal. So, if you set variables_order = "GP" because you only want Get a

Re: [PHP-DEV] variables_order annoyance

> Check out this bug report: > > http://bugs.php.net/16155 Ah thanks, that's where I remember the discussion from. I do disagree with one part: (c) It shouldn't be possible to prevent $_GET, $_POST, $_COOKIE, and $_FILES from being populated. Why in the world not? I explicitly ne

[PHP-DEV] request data filter

In trying to implement a security policy I need to pass all user-supplied data (GET/POST/Cookie) through a filter function which implements this security. This isn't all that hard to implement as an extension through new 4.3 treat_data and post_handler hooks, however it gets messy when you throw m

Re: [PHP-DEV] request data filter

On Wed, 15 Jan 2003, George Schlossnagle wrote: > You consider running the apache_hooks code? This should be simple > there. You mean do the filtering straight from a PHP script that gets called from a hook? That's a lot of looping through a bunch of arrays. This has to happen on every requ

Re: [PHP-DEV] request data filter

> You could have your custom C extension be called as one of the hooks. I suppose I could munge with the apache tables directly in a hook before the data is read by the standard treat_data hook, although for post data I am not sure I have any way to get in there before the ap_get_client_block() ca

Re: [PHP-DEV] 4.3.1 (was: [PHP-CVS] cvs: php4(PHP_4_3) /main SAPI.h)

> > Who said that we're not going to release a 4.3.1 or 4.3.n? I'm just not > > favoring new code going into the PHP_4_3 branch, but only bugfixes. I'd > > like to see new functionality going into HEAD, for PHP 5. > > You might favor that, but I don't pretend that PHP 5.x will > become use

Re: [PHP-DEV] request data filter

>I cannot agree more. There is only so much you can do outside >the PHP (as I do in mod_security). I've finished the code. I'll run it through its paces here and commit it soon. -Rasmus -- PHP Development Mailing List To unsubscribe, visit: http://www.php.net/un

Re: [PHP-DEV] roadmap of PHP - where? PHP 5 - when?

> I would like to know in advance when PHP 5 will be released. So would we. We have no idea. Sometime in the next 4-18 months. How's that? > Can I find a sort of "roadmap" somewhere? We are well past the roadmap and into the TODO stage now. Our trusted secretary, Sebastian, has been maint

RE: [PHP-DEV] roadmap of PHP - where? PHP 5 - when?

On Thu, 23 Jan 2003, John Coggeshall wrote: > The reason I ask is that Shane Caraveo and I were working on the thread > saftey issue, but we couldn't talk about it because we weren't invited > to the PHP5-DEV list I had nothing to do with that limited php5 list. I thought that was completely bog

Re: [PHP-DEV] roadmap of PHP - where? PHP 5 - when?

On Thu, 23 Jan 2003, Zeev Suraski wrote: > Ok, I can't be bothered to fight a mailing list that was supposed to trim > down endless discussions. I'm not the one that asked for the list, but I > definitely supported it, as unlike most of the members on this list, I > remember the pre-v4 days, and

[PHP-DEV] Reducing the number of system calls for includes

Take this script: So, a simple include with an absolute pathname to avoid any include_path searching and all safe_mode and open_basedir checking turned off. The latter of course being an absolute killer. We still need a lot of system calls to handle this include: getcwd("/home/rasmus", 40

Re: [PHP-DEV] Reducing the number of system calls for includes

On Sat, 25 Jan 2003, Sascha Schumann wrote: > > files list. It's handy and nice to normalize the path here, but it is > > really really expensive! > > ..only on systems with ultra slow syscall setup procedures > (e.g. Solaris) or lack of directory cache. > > > Due to our current impleme

Re: [PHP-DEV] Reducing the number of system calls for includes

> >As for numbers, I basically doubled the req/sec rate of a box by > >eliminating a bunch of system calls caused by include_path and > >open_basedir stat'ing, so in my particular situation here eliminating as > >many syscalls as I can is having a direct effect. > > What OS are you running on? Are

Re: [PHP-DEV] Reducing the number of system calls for includes

> I can't really think of any way of getting around this. include_once() and > require_once() are basic language constructs and they require this. Well, they require us to be able to uniquely identify a file, they do not necessarily require us to know the canonical filename. This could be done

Re: [PHP-DEV] Reducing the number of system calls for includes

On Sat, 25 Jan 2003, Andi Gutmans wrote: > At 04:32 PM 1/24/2003 -0800, Rasmus Lerdorf wrote: > > > I can't really think of any way of getting around this. include_once() and > > > require_once() are basic language constructs and they require this. > > > &

Re: [PHP-DEV] Reducing the number of system calls for includes

> Eliminating realpath for fully qualified paths make sense to me. > > But... don't you Y! guys use php-a? Shouldn't this hide that overhead > completely from you by completely eliminating all the stats on a > require/include after the initial compilation? Or is this just a It doesn't elimi

Re: [PHP-DEV] Reducing the number of system calls for includes

> Weird. That was totally contrary to the way I remember it working. In > trying to figure out why I remembered incorrectly, I realized the > reason why you (in general) want to resolve the path to a canonical > path is that you can seriously break include_once and require_once if > you dont.

Re: [PHP-DEV] Reducing the number of system calls for includes

> That said, we could possibly have a fast mode and use fstat() to get some > device information on the open file. I am worried about functionality > though. I'm not sure it's worth breaking. Yes, fstat() is fast. And perhaps it isn't worth breaking functionality across the board, but in my pa

Re: [PHP-DEV] Reducing the number of system calls for includes

> The question here is whether it's worthwhile to optimize for > the case where you have 30+ includes per page. Is it that > common? In my particular case just 2 or 3 includes puts me over the top actually. stat() is amazingly slow on freebsd and having 3 includes of files in a dir

Re: [PHP-DEV] Reducing the number of system calls for includes

> >Another idea would be to try to streamline the normal case for an absolute > >pathname. How about doing a readlink() on it. If that tells us that it > >is a link, then we know there is something funky and we can do a realpath, > >otherwise we just assume it is canonical assuming there are no .

Re: [PHP-DEV] Reducing the number of system calls for includes

> I think the best solution to this problem, without breaking functionality, > is to use a cache for realpath() in virtual_file_ex(). > This should solve the performance problems and not effect BC at all. As > TSRM always passes a full path to the realpath() call there, it should > always work.

Re: [PHP-DEV] Reducing the number of system calls for includes

> Don't you have any FreeBSD kernel hackers in Y!? You could probably > convince/bully one of them to fix it, that's what we always do with ours > here ;-) Turns out that one of the problems is that the standard 0x80 way of doing a syscall is rather slow on the P4 chip. P3 and Athlon chips are

Re: [PHP-DEV] [PATCH] Apache 2.0 Handler module

You guys have CVS access, and thus you make the call on what gets accepted or not. There is no higher power here, you guys know the Apache2 stuff better than most. You only start getting pushback if you start changing existing code that might break stuff. -Rasmus On Tue, 11 Feb 2003, Ian Hol

Re: [PHP-DEV] Re: [PHP] Threading

On Tue, 18 Feb 2003, Greg Donald wrote: > On Tue, 18 Feb 2003, Bruce Miller wrote: > > >Will PHP allow multiple-thread execution? > > PHP4 does not have thread support. Well, except for pear/PECL/threads, of course. -Rasmus -- PHP Development Mailing List To unsubscribe

Re: [PHP-DEV] file_put_contents() / file_add_contents() ?

On Fri, 21 Feb 2003, Ilia A. wrote: > On February 21, 2003 09:38 am, Sascha Schumann wrote: > > > implode) and fclose. However, IMO this wrapper is very useful since it > > > simplifies commonly used code a great deal and even makes it slightly > > > faster since the wrapper is in C rather then in

[PHP-DEV] Performance degradation

So, I am just starting out down the path to figure out why PHP 4.3 has gotten so much slower than 4.2. "strace -c" provides the first clue. A straight "./configure --enable-inline-optimization && make" command-line build for 4.2, 4.3 and 5.0 run on a simple hello world script reveals that we have

Re: [PHP-DEV] Performance degradation

On Sun, 23 Feb 2003, Stanislav Malyshev wrote: > RL>> So, obviously these opens don't really affect the module version > RL>> since they only happen on startup, but they still don't seem right. > RL>> I understand ./php-cgi.ini, but .//php-cgi.ini and .//php.ini? > RL>> Looks like a missing check

[PHP-DEV] Performance degradation part 2 the module version

A little bit harder to get clean output on this one. The numbers in the <>'s are the times for the system call. Here is a 4.2 hello world request: accept(24, {sin_family=AF_INET, sin_port=htons(57198), sin_addr=inet_addr("10.0.1.254")}}, [16]) = 3 <4.035087> rt_sigaction(SIGUSR1, {SIG_IGN}, {0x

Re: [PHP-DEV] Performance degradation part 2 the module version

On Sun, 23 Feb 2003, Jim Jagielski wrote: > Rasmus Lerdorf wrote: > > > > Even in 4.2, I think we can optimize it. Assuming chdir() doesn't return > > an error, we shouldn't need that second getpwd() call since we just did > > the chdir() and we should know

Re: [PHP-DEV] Performance degradation

On Sun, 23 Feb 2003, Shane Caraveo wrote: > Rasmus Lerdorf wrote: > > So, I am just starting out down the path to figure out why PHP 4.3 has > > gotten so much slower than 4.2. "strace -c" provides the first clue. A > > straight "./configure --enable-inlin

[PHP-DEV] extra realpath() found

Hey Sander, you fixed a problem back in July where you introduced a second realpath() call into the main execute_script() function. I understand what you were trying to achieve, but realpath() is way way too expensive to toss around like that, especially since we already do the realpath on the fop

Re: [PHP-DEV] Performance degradation part 2 the module version

> Have you been testing PHP_4_3 from CVS or the actual 4.3.0 release? > You might find the situation slightly better using the latest (I tidied > up some seek related issues the other day). The straces are from PHP_4_3 HEAD as of this morning. I thought originally that these issues were just a ha

Re: [PHP-DEV] patch for binary-safe strip_tags()

Looks fine to me. On Tue, 25 Feb 2003, Moriyoshi Koizumi wrote: > Hi, > > Attached is the patch for binary-safe strip_tags(). > Although it doesn't appear to be harmful anyhow, I think it needs > review since it modifies rather sensitive part. > > Any objections? > > Moriyoshi > > -- PH

Re: [PHP-DEV] Performance degradation part 2 the module version

On Sun, 23 Feb 2003, Wez Furlong wrote: > This double seeking is most probably due to the fact that the stdio > layer does one set of seeking, whereas streams needs to do another. > > This can be solved by moving away from using stdio for streams, and just > using the "raw" descriptors instead. (

Re: [PHP-DEV] Performance degradation part 2 the module version

> Admittedly, when opening the file for the first time, we do not need to > seek - so we can avoid it by passing a flag (OR'd with the REPORT_ERRORS > flag). > > I'm sure we can eliminate those seeks. Are there any other areas in the > streams code that you can see that could do with a syscall tu

Re: [PHP-DEV] Performance degradation part 2 the module version

> I'm sure we can eliminate those seeks. Are there any other areas in the > streams code that you can see that could do with a syscall tune-up? Ok, found two more. In _php_stream_fopen() we fstat() the script to be opened: realpath = expand_filepath(filename, NULL TSRMLS_CC); fp = fop

Re: [PHP-DEV] Re: Announcement: Next generation ext_skel

The current one does, so it better... On Wed, 19 Feb 2003, l0t3k wrote: > Hartmut, > will this also generate zend_parse_parameters calls based on prototype ? > > l0t3k > "Hartmut Holzgraefe" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > > > i've just added the first working

[PHP-DEV] Flex never-interactive mode

I think we can add "%option never-interactive" to the ini-scanner lexer to speed it up a tiny little bit. Speeding up the ini scanner might be important for the folks running the cgi version. More importantly, to me anyway, when we know we are not interactive, should we not programmatically set i

Re: [PHP-DEV] Flex never-interactive mode

On Wed, 26 Feb 2003, Andi Gutmans wrote: > At 12:48 PM 2/26/2003 -0800, Rasmus Lerdorf wrote: > >I think we can add "%option never-interactive" to the ini-scanner lexer to > >speed it up a tiny little bit. Speeding up the ini scanner might be > >important for th

Re: [PHP-DEV] New extension: netfilter

On Fri, 28 Feb 2003, Corne' Cornelius wrote: > Can i code a netfilter extension for PHP or don't you guys see the need > for it ? > It could result in some great firewall frontends in PHP Go for it. Assuming the netfilter library is not under the GPL. LGPL is fine. -Rasmus -- PHP Development

Re: [PHP-DEV] [PATCH] - fix for 64 bit issues with OnUpdateInt

On Fri, 28 Feb 2003, Andi Gutmans wrote: > At 04:50 PM 2/28/2003 +0100, Sascha Schumann wrote: > > I think that simply adding OnUpdateLong and deprecating > > OnUpdateInt is fine while retaining its current semantics. I > > just don't see any value in changing the meaning of > > O

Re: [PHP-DEV] Tie'ing variables

> Analyzing PHP's routines a bit, it seems that the slowest part of a > "generic" request is populating the special arrays, $_ENV, $_GET, etc. Do you have any profiling evidence of this? Everything I have looked at points squarely at the parts of PHP that requires a system call. Reducing syste

Re: [PHP-DEV] magic_quotes on the environment?

> I'm not convinced that escaping environment data is the correct thing to > do in the first place, and I would like to change php to not escape env > vars if magic_quotes_gpc is on. Any opinions on this? This changed somewhere along the line then. Originally magic quotes only touched GPC dat

[PHP-DEV] Re: [PHP] 'make' PHP4.3.1 returns the use of function`tempnam' isdangerous --- WHY?

> When I tried to 'make' PHP-4.3.1, it returns warning message and died. I am > using RH8.0 + Apache 2.0.44 It didn't die, that is simply the end of the build. Warnings aren't fatal. (Please do not cc all the lists) -Rasmus -- PHP Development Mailing List To unsubscri

[PHP-DEV] Re: #22527 [Opn->Bgs]: Modulus returned negative value

This is actually an interesting question. Should we be truncating towards zero? I'd say yes, but then I tested Perl, Python and Tcl, and they all say that -27 % 7 is 1 which means they truncate towards negative infinity. Too late to change at this point in the game, but perhaps it calls for a mo

Re: [PHP-DEV] Re: #22527 [Opn->Bgs]: Modulus returned negative value

> numbers in canonical representation of Z/bZ). I guess perl/python/tcl > ddecided to adhere to the mathematical definition. > > > On Tuesday, March 4, 2003, at 02:37 AM, Rasmus Lerdorf wrote: > > > This is actually an interesting question. Should we be truncating

Re: [PHP-DEV] Re: #22527 [Opn->Bgs]: Modulus returned negative value

On Tue, 4 Mar 2003, Sascha Schumann wrote: > > Well, Perl can lean the other way as well actually. Try this: > > Is there some documentation why the default is as it is? All I could find was this description of the Perl modulus operator: Binary ``%'' computes the modulus of two numbers.

Re: [PHP-DEV] CVS access

Unless I am missing something, I don't see how this stuff belongs in PHP CVS at all. Could you explain why you think this needs to be in the core language CVS? -Rasmus On Mon, 10 Mar 2003, [iso-8859-2] Ján Šuňavec wrote: > I need CVS access into PHP CVS repository. I have project with code > na

Re: [PHP-DEV] Language Auto Detection / www.php.net

> What browser denies you from setting this accept-language thing? > You do have control over it, and it is far more general then > having a cookie in the browser. Which is also not that flexible, > as we would probably only store one language code. Gabor, the problem is that you can't override it

Re: [PHP-DEV] PHP Lists not hiding email address

On Tue, 11 Mar 2003, Ryan wrote: > Hi, > > I'm getting a lot of spam leading from some of the pages on > zend.com/lists/php-dev/ > > The bug edit pages hide the email address. But the static archives like > http://www.zend.com/lists/php-dev/200110/msg02161.html > don't hide them. > > Could you

Re: [PHP-DEV] Moderate PHP-DEV

> > We don't lose anything by giving the first two items some > > time to prove their usefullness. On the other hand, it is > > very likely that we will lose useful input, if we implement > > the third item prematurely. > > I disagree. Anyone here can handle replying because we alr

Re: [PHP-DEV] compiling PHP_4_3

Did you actually check out version 4.3? cvs co -r PHP_4_3 php4 Check your CVS/Entries file. You should see the branch name after each file. -Rasmus On Thu, 13 Mar 2003, Corne' Cornelius wrote: > Hi, > > I compiled CLI version of PHP_4_3 this morning and it gave the following: > > php4/main/

[PHP-DEV] trans-sid warning?

As much as I think trans-sid sucks from a performance perspective, what's with this comment in php.ini-dist? ; trans sid support is disabled by default. ; Use of trans sid may risk your users security. It may not be ; feasible to use this option for some sites. Use this option with caution. sessi

Re: [PHP-DEV] trans-sid warning?

Guys, documentation is about giving people information that will help them solve problems, not about FUD. That was my original point about the php.ini entry. You can't just state that something is very very bad without giving workable solutins and alternatives. Present ways of solving the probl

[PHP-DEV] Gathering library thread safety info

Folks, I started a table here: http://httpd.apache.org/docs-2.0/developer/thread_safety.html To try to get started down the bumpy road of figuring out which PHP extensions are likely to be thread unsafe based on their usage of thread unsafe libraries. Please help out by either adding more libra

Re: [PHP-DEV] trans-sid warning?

> Edin Kadribasic wrote: > > > > > I absolutely agree with Stefan here. It is *not* PHP's job to > > secure > > > a connection. SSL does this. > > > > Like that's going to stop users from pasting url with SID in it to > > an email, which is what this thread is about. > > > > Edin > > The issue is

[PHP-DEV] Re: [PHP-DOC] Re: #3793 [Ana->Opn]: session.gc_maxlifetime does notwork

Ok, thinking a bit more about this.. session_readonly() really should be implemented. Imagine a system where you have dynamically generated images/flash/pdf or even just a straight framed site. You use sessions to pass information around between not only pages, but also to the dynamically gener

Re: [PHP-DEV] Re: [PHP-DOC] Re: #3793 [Ana->Opn]: session.gc_maxlifetimedoes not work

nt to use mtime or atime, so that non atime-compliant filesystems > >can still be supported, but we leave the window to support > >session-readonly in the future. > > > >Zeev > > > >At 07:37 17/08/2002, Rasmus Lerdorf wrote: > >>Ok, thinking a bit

Re: [PHP-DEV] 4.2.3

Regardless of what we call it, we need to light a fire under people to get a new release out. The fixes are piling up in CVS. Stig, could you give us a status report? Do you still have time to push this release? -R On Sat, 17 Aug 2002, Zeev Suraski wrote: > Ok then, I retract my suggestion t

[PHP-DEV] Re: #18655 [Bgs->Csd]: strtotime() with "next Sunday"

Yup, but it is one of those "clearly wrong" cases. On Sat, 17 Aug 2002, Derick Rethans wrote: > On 30 Jul 2002 [EMAIL PROTECTED] wrote: > > > Yeah, reading a bit more it looks like you are right. I have fixed > > this in CVS now. "next" maps to "2" now instead of "1" > > Doesn't this break bac

Re: [PHP-DEV] trans-sid warning?

> Any propagation, doesn't matter. > The passed id must exist, otherwise discarded and regenerated. > I saw that php already creates the session at the start. > > The possibility to count on a stable name, because recreable anytime > and though surviving gc, is a great weaknes for that tipe of sno

Re: [PHP-DEV] trans-sid warning?

2002, Giancarlo wrote: > Rasmus Lerdorf wrote: > > > > > Any propagation, doesn't matter. > > > The passed id must exist, otherwise discarded and regenerated. > > > I saw that php already creates the session at the start. > > > > > > The

Re: [PHP-DEV] Re: [PHP-DOC] Re: #3793 [Ana->Opn]: session.gc_maxlifetime

Well, I wouldn't call that easy. To do it in the session handler you would need to add a bunch of code to the write handler. It would need to read the current session data, then compare that to the session data it was called with, and if different write the new session data. You aren't saving m

Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

I don't think we should stop people from tweaking ZE1. ZE2 is probably more than a year away from realistically being available to a lot of people. It takes a while for people to upgrade, and many will skip the .0 release. If a few tweaks to ZE1 can eliminate peoples' motivation to move to ZE2, t

Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

> At 20:29 18/08/2002, Rasmus Lerdorf wrote: > >I don't think we should stop people from tweaking ZE1. ZE2 is probably > >more than a year away from realistically being available to a lot of > >people. > > No, it's not. It's around 6 months away from b

Re: [PHP-DEV] trans-sid warning?

Hrm.. Wait a second though, Giancarlo is saying that if the user passes in a session id himself and that session does not exist, then that will be the session id he will be given if a session is created on that request. Is that correct, Giancarlo? >From looking at the code and testing that assum

Re: [PHP-DEV] trans-sid warning?

> Il 23:54, domenica 18 agosto 2002, Rasmus Lerdorf ha scritto: > > Hrm.. Wait a second though, Giancarlo is saying that if the user passes > > in a session id himself and that session does not exist, then that will be > > the session id he will be given if a session is cr

Re: [PHP-DEV] trans-sid warning?

Ok, then that is a bug that needs to be fixed before 4.3. On Mon, 19 Aug 2002, Giancarlo wrote: > Il 00:13, lunedì 19 agosto 2002, hai scritto: > > > Il 23:54, domenica 18 agosto 2002, Rasmus Lerdorf ha scritto: > > > > Hrm.. Wait a second though, Giancarlo is

Re: [PHP-DEV] trans-sid warning?

o see changed/fixed? The second one being the implementation of session_readonly() and the accompanying control of whether the gc uses atime or mtime to gc sessions. -Rasmus On Mon, 19 Aug 2002, Yasuo Ohgaki wrote: > Rasmus Lerdorf wrote: > > Ok, then that is a bug that needs to be fi

Re: [PHP-DEV] a patch for making a webdav server work

Well, the stuff I did in the apache_hooks branch shows how you can hook into other stages of the request chain and, for example, define a PHP script to be called at the url translation stage or the auth stage. The latter would allow you to perform PHP-based auth on all files, not just PHP files,

Re: [PHP-DEV] a patch for making a webdav server work

> nope. OPTIONS is not handled at all by PHP at the moment, therefore i made > this change with accept_options (OPTIONS is explicitely blocked right > now). The other primitives which have POST data (see > http://asg.web.cmu.edu/rfc/rfc2518.html for the details) > > PROPFIND > PROPPATCH > PUT > MO

Re: [PHP-DEV] Re: [PHP-DOC] Re: #3793 [Ana->Opn]: session.gc_maxlifetime

On Mon, 19 Aug 2002, Yasuo Ohgaki wrote: > Zeev Suraski wrote: > > I don't think that's the way to do it at all. In theory, it's no > > problem to track whether changes were made to the session data, and > > perform the write at the end of the request, only if we tracked a > > change. That's on

Re: [PHP-DEV] a patch for making a webdav server work

Yeah, they are. That's why they are on a branch and haven't really gone anywhere. They are destabilizing and I don't have the free time required to integrate them and test them properly at this point. -Rasmus On Mon, 19 Aug 2002, Wez Furlong wrote: > The apache_hooks looks like it's a lot mor

Re: [PHP-DEV] PECL compilation

run phpize in the extension's dir On 19 Aug 2002, Dan Helfman wrote: > Perhaps I just haven't looked hard enough, but I can't find any > information on how PECL software is supposed to be compiled (in CVS). > Most PECL packages just have a config.m4 and a Makefile.in, but no > configure.in, buil

Re: [PHP-DEV] trans-sid warning?

> Rasmus Lerdorf wrote: > > No, I think the check we need here is one that checks to see if the > > session specified in the user-supplied PHPSESSID exists. If it does not > > exist, toss that session id and replace it with a PHP-generated one. > > > > Perhaps

Re: [PHP-DEV] trans-sid warning?

Well, while it is true that it is impossible to completely prevent, our current setup doesn't do anything at all to prevent it which makes the attack much simpler. There is currently no need for the attacker to visit the site to be attacked at all and thus he doesn't need any keepalive stuff to m

Re: [PHP-DEV] trans-sid warning?

> matching ip limits the number of session hijackings to atleast the same > network you are on (behind a fw/router which does nat), and the users who > use the same http proxy as you (in case you use one) > > so its either expire/generate (rotate,morph,mutate) SID on each pageload, or > the more p

Re: [PHP-DEV] trans-sid warning?

But could you at least answer the question? What is the advantage of allowing user-supplied new session ids? I see no reason not to add a check for this. On Tue, 20 Aug 2002, Sascha Schumann wrote: > On Mon, 19 Aug 2002, Rasmus Lerdorf wrote: > > > Well, while it is true that it i

Re: [PHP-DEV] trans-sid warning?

> On Mon, 19 Aug 2002, Rasmus Lerdorf wrote: > > > But could you at least answer the question? What is the advantage of > > allowing user-supplied new session ids? I see no reason not to add a > > check for this. > > For example, I have a set of C programs fo

Re: [PHP-DEV] Tests..

I think it would be hard to distinguish when a positive test result is not important. For example, the SAPI module checks we would want to see the 'yes' result and not all the 'no' results since they are meaningless. What I would like to see is a nice summary at the end that gives some useful inf

RE: [PHP-DEV] trans-sid warning?

in as: you loged in with the following IPaddr/Uagent: >blablah. > > Xavier. > > -Original Message- > From: Sascha Schumann [mailto:[EMAIL PROTECTED]] > Sent: Mon 19/08/2002 8:50 PM > To: George Schlossnagle > Cc: Rasmus Lerdorf;

Re: [PHP-DEV] strange bug in bugs.php.net

Ok, I've fixed this. When the cvs change propogates to the rsync server and the next rsync update cron job from bugs.php.net runs, this change will be visible... So try again in about 2 weeks. ;) On Tue, 20 Aug 2002, Sebastian Nohn wrote: > Hi, > > to reproduce this: > > -> http://bugs.php.net

Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

> I still think it shouldn't go in. This is the only feature in Engine 2 > which might make non-OOP people convert. Once this isn't in Engine 2 we > don't have a carrot for them. Why can't you respect this way of > thinking? Especially as I wrote the code? You're basically saying screw > them beca

Re: [PHP-DEV] liveUser

Was this intended for pear-dev? On Tue, 20 Aug 2002, Lukas Smith wrote: > Hi, > > we really need this to be resolved ASAP. > I have written quite a few changes into my version of liveUser and I am > sure there are other people that are interested in seeing what's going > on. > > I really don’t c

Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

> >We have a feature that doesn't destabilize anything or slow anything down > >as far as I can tell, and would be very useful to a whole bunch of users > >today. If that single point is not more important than anything else, then > >we are getting completely offtrack here. > > I disagree. Exactl

Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

> By the way, the only personal gain I have in getting ZE2 out of there is > that it's my code and that PHP will do much better. I think that PHP is > going to loose out big time if things don't start gaining some momentum. > Backporting is definitely a momentum breaker *especially* as everyone >

Re: [PHP-DEV] Tests..

Ah, yeah, that'd be ok. On Tue, 20 Aug 2002, Jani Taskinen wrote: > > Heh..I should have said that I meant the regression tests.. :) > configure is fine as it is. :) > > --Jani > > > -- > > On Mon, 19 Aug 2002, Rasmus Lerdorf wrote: > > >

Re: [PHP-DEV] new webdav patch

It is getting there. You are checking for POST under webdav_methods when POST is already allowed by default, so it is a redundant strcmp(). Otherwise your patch looks ok. Anybody else here have an issue with adding this configue option which will allows webdav methods through to be handled in us

Re: [PHP-DEV] new webdav patch

> On Tue, 20 Aug 2002, Rasmus Lerdorf wrote: > > > It is getting there. You are checking for POST under webdav_methods when > > POST is already allowed by default, so it is a redundant strcmp(). > > oops. that one slipped through and was certainly not intended to be there

Re: [PHP-DEV] tests tweaks

I changed it actually, but you are right, that was the reason. On Wed, 21 Aug 2002, Yasuo Ohgaki wrote: > Marcus Börger wrote: > > 1) someone must have changed ini setting precision from 14 to 12 > > Adding special INI section to array tests fixed test 1 & 2. > > IIRC, Zeev changed this to avoid

RE: [PHP-DEV] PHP 4.3 and PHP 5

But how do you propose we come up with perfect Apache 2.0 support? If we limit it to the pre-fork mpm, we can probably get quite close to perfect stability, but for any of the threaded mpms we are completely at the mercy of the threadsafetyness of all the various third party libraries on all the v

Re: [PHP-DEV] libgd patch for alpha-channel mixing

I've looked at these before and they look ok to me. That was the point of bringing libgd inhouse. Of course, we will have to carefully document the fact that some GD functions are only available with the bundled version of libgd. I can live with that hassle in exchange for bug fixes and added f

Re: [PHP-DEV] libgd patch for alpha-channel mixing

> Wouldn't it be preferable for the function to be there and report the reason > it doesn't work, ie "this function only works when using the bundled GD > library"? No, because then people can't write portable code that checks using function_exists() -Rasmus -- PHP Development Mailing List

Re: [PHP-DEV] PHP 4.3 and PHP 5

the Apache cvs server, but you can bounce any additions through me. I did it at the Apache level since I am trying to leverage the knowledge the mod_perl folks have as well. -Rasmus On Thu, 22 Aug 2002, Kristian Koehntopp wrote: > Am Mittwoch, 21. August 2002 22:09 schrieb Shane

Re: [PHP-DEV] PHP 4.3 and PHP 5

On Thu, 22 Aug 2002, Kristian Koehntopp wrote: > Am Donnerstag, 22. August 2002 09:43 schrieb Rasmus Lerdorf: > > Putting in locks is the easy part. The tough part is finding > > which libraries are safe and which ones aren't. > > I think that is easy, too. Either th

Re: [PHP-DEV] [RFC] apache_hooks update

Does it work? On Thu, 22 Aug 2002, Lukas Schroeder wrote: > hi, > > attached is a first request for comment for an update to the > apache_hooks code. > > > a php-handler for uri translation looks like this ($request is of type > ApacheRequest). > > > $request->uri('/s.html'); > return DECLI

Re: [PHP-DEV] Re: [rfc] apache_hooks update (yet incomplete)

I say commit it. This stuff is very experimental as it is and lives in its own branch. You are not going to destabilize anything. (I just made sure you had enough karma for the commit) -Rasmus On Mon, 26 Aug 2002, George Schlossnagle wrote: > Here's an incremental patch on Lukas' patch which

Re: [PHP-DEV] Re: [rfc] apache_hooks update (yet incomplete)

? On Mon, 26 Aug 2002, George Schlossnagle wrote: > All of this work was off HEAD. Should a new_apache_hooks branch be tagged? > > Rasmus Lerdorf wrote: > > >I say commit it. This stuff is very experimental as it is and lives in > >its own branch. You are not

Re: [PHP-DEV] Re: [rfc] apache_hooks update (yet incomplete)

work fresh off of head, and I made changes > off of that, so it contains nothing from your apache_hooks branch. > > Rasmus Lerdorf wrote: > > >I think if we put this in 4.3 we are going to delay 4.3 even further. > >Although, I suppose if we are careful and make sure we #i

Re: [PHP-DEV] Re: [rfc] apache_hooks update (yet incomplete)

> On Mon, 26 Aug 2002, Rasmus Lerdorf wrote: > > > Well, the problem with doing it on a branch, the way I did, and as Lukas > > found out, is that it goes rather stale after a while. So I guess that I > > am actually proposing putting it in HEAD but #ifdef'ed

  1   2   3   4   5   6   7   8   9   >