On Fri, 7 Feb 2003, Stas Bekman wrote:
> I haven't seen any activity with maintaining tests in a while and I have a
> bunch of ssl tests failing. I remember Ryan working on a new test suite.
> What's the current status of things? Should Joe's new php tests be committed?
>
> These fail for me:
>
>
On Thursday 06 February 2003 20:23 pm, you wrote:
> At 06:00 PM 2/6/2003, NAIK,ROSHAN (HP-Cupertino,ex1) wrote:
>
> And finally, TLS storage is a huge obstacle to ever implementing any
> multithreaded, async server that might service some request from
> multiple threads. Such a design might start
At 06:00 PM 2/6/2003, NAIK,ROSHAN (HP-Cupertino,ex1) wrote:
>Also blaming on use of TLS seems a little strange since use of TLS is
>supposed to improve re-entrancy isn't it ?
That's something of a misunderstanding... so I'll take a second to offer
an example of the difference.
Thread-safe code
Rather than fix the TS issues in all the 3rd party libraries that can be
used
with PHP's and its extension its more pragmatic to sort out thread/filter
issues
in PHP core. Since similar arguments can be made for Apache core too.
The same issue has certainly not stopped Apache 2.0 itself from goin
I'm very close to an outright veto of such a change, at this time...
My reason is pretty simple... a good chunk of bugzilla reports have revolved
around one broken sendfile implementation or another. This isn't specific to
a small handful of platforms. It is a problem across various nfs and oth
> Perhaps it's best for someone to simply port php4apache to 2.0 and start
> moving a little momentum. The thread-safety arguement is a little bogus,
> until folks have something to start finding thread-safety bugs. How long
> have Win32 users been doing PHP within threaded servers?
We have gott
Between 2.0.43 and 2.0.44, the performance of SPECweb99 standard dynamic GETs
has degraded about 7%. Static files are fine, and ab benchmarks of small
dynamic requests are also fine. oprofile + strace shows that the difference
with the SPEC dynamic requests is that sendfile is no longer used i
At 12:15 PM 2/6/2003, Bill Stoddard wrote:
>Aaron Bannert wrote:
>>On Wednesday, February 5, 2003, at 08:39 AM, Bill Stoddard wrote:
>>
>>>Then reimplement PHP as a handler/generator. You get the benefits of being able to
>install downstream filters w/o the headaches of implementing a filter. Pe
On Thu, 6 Feb 2003, Dmitri Tikhonov wrote:
> On Thu, Feb 06, 2003 at 07:42:56PM +0100, Sascha Schumann wrote:
> > On Thu, 6 Feb 2003, Dmitri Tikhonov wrote:
> >
> > > On Thu, Feb 06, 2003 at 06:51:06PM +0100, Sascha Schumann wrote:
> > > > > I have Apache 2 and PHP running with no big problems so
On Thu, Feb 06, 2003 at 07:42:56PM +0100, Sascha Schumann wrote:
> On Thu, 6 Feb 2003, Dmitri Tikhonov wrote:
>
> > On Thu, Feb 06, 2003 at 06:51:06PM +0100, Sascha Schumann wrote:
> > > > I have Apache 2 and PHP running with no big problems so far.
> > >
> > > Two concurrent php script execut
On Thu, 06 Feb 2003 19:47:52 +0100, Sascha Schumann wrote:
>> is php re-entrant? or does it use globals/thread specific storage. if it
>> does than php can not be used in a subrequest.
>
> It's not reentrant-safe and it uses TLS.
>
> - Sascha
ok.. then we have a major problem, limiting
> is php re-entrant? or does it use globals/thread specific storage. if it
> does than php can not be used in a subrequest.
It's not reentrant-safe and it uses TLS.
- Sascha
Ian Holsman wrote:
On Thu, 06 Feb 2003 13:22:28 -0500, Bill Stoddard wrote:
Of course you still won't be able to embed php scripts in SSI tags (w/o
doing unnatural things) but who really cares?
how so?
if we just make a rule saying that sub-requests don't get post data then
we could handle m
> In any case, the mod_cgi solution gets us back to the same
> problem we've always had with PHP, which is that we can't
> buffer the entire input body w/o having a huge memory impact on
> multithreaded servers. (We would need to buffer it because
> of the way PHP expects to consume input data.)
Aaron Bannert wrote:
On Thursday, February 6, 2003, at 10:15 AM, Bill Stoddard wrote:
Also, I should point out that something as seemingly simple
as an SSI file that includes multiple php scripts needs the
filter stack.
So is that a popular configuration in use with 1.3 today? If not,
then
On Thu, 6 Feb 2003, Dmitri Tikhonov wrote:
> On Thu, Feb 06, 2003 at 06:51:06PM +0100, Sascha Schumann wrote:
> > > I have Apache 2 and PHP running with no big problems so far.
> >
> > Two concurrent php script executions might not work at all,
>
> I forgot to mention that I use preforking mod
On Thu, 06 Feb 2003 13:22:28 -0500, Bill Stoddard wrote:
>
> Of course you still won't be able to embed php scripts in SSI tags (w/o
> doing unnatural things) but who really cares?
how so?
if we just make a rule saying that sub-requests don't get post data then
we could handle multiple php scrip
On Thursday, February 6, 2003, at 10:22 AM, Bill Stoddard wrote:
ROTFL...
This explains my earlier observation re "if the only tool you have
(amendment: or think you have) is a hammer, every problem looks like a
nail" :-)
Seriously, handlers exist in 2.0 (see modules/generators) and the APIs
On Thursday, February 6, 2003, at 10:15 AM, Bill Stoddard wrote:
Also, I should point out that something as seemingly simple
as an SSI file that includes multiple php scripts needs the
filter stack.
So is that a popular configuration in use with 1.3 today? If not,
then I hold this up as a tro
Aaron Bannert wrote:
Now, we could solve both problems by using a handler and
the prefork MPM. But then, Apache 2.0+PHP is basically
Apache 1.3+PHP with a few extra modules thrown in. That's
how it appears to the end-user at least.
I don't buy that argument. Are you saying t
Aaron Bannert wrote:
On Wednesday, February 5, 2003, at 08:39 AM, Bill Stoddard wrote:
Then reimplement PHP as a handler/generator. You get the benefits of
being able to install downstream filters w/o the headaches of
implementing a filter. Personally I never thought implementing PHP as
a
On Wednesday, February 5, 2003, at 08:39 AM, Bill Stoddard wrote:
Then reimplement PHP as a handler/generator. You get the benefits of
being able to install downstream filters w/o the headaches of
implementing a filter. Personally I never thought implementing PHP as
a filter was a good idea
On Thu, Feb 06, 2003 at 06:51:06PM +0100, Sascha Schumann wrote:
> > I have Apache 2 and PHP running with no big problems so far.
>
> Two concurrent php script executions might not work at all,
I forgot to mention that I use preforking model.
- Dmitri.
On Thu, Feb 06, 2003 at 06:50:08PM +0100, Sascha Schumann wrote:
> > > Is it really #1 module?? *sigh*
> >
> > Yup, by far.
>
> You can find the current data here:
>
> http://www.securityspace.com/s_survey/data/man.200301/apachemods.html
Something is fishy there. How would one account
--On Thursday, February 6, 2003 9:07 AM -0500 Bill Stoddard
<[EMAIL PROTECTED]> wrote:
ap_http_filter logic in the header parser filter, create a new API
to push bytes back to the core_input_filter when the header parser
filter reads too many bytes and variations.
Eww.
Regardless, I'll wait to
Aaron Bannert wrote:
There is no such thing anymore as a handler in Apache 2.0, am I correct?
no, see default_handler, modules/generators/mod*.c
Aren't the handler-like hooks that try to behave the same was as they did
in 1.3 just implemented over output filters?
sure, output goes down fi
On Wednesday, February 5, 2003, at 08:27 AM, Joshua Slive wrote:
On Wed, 5 Feb 2003, Sascha Schumann wrote:
Now, we could solve both problems by using a handler and
the prefork MPM. But then, Apache 2.0+PHP is basically
Apache 1.3+PHP with a few extra modules thrown in. That's
> I have Apache 2 and PHP running with no big problems so far.
Two concurrent php script executions might not work at all,
if you look at the code. Maybe I'll spent some time today on
it and use fopencookie to create a proper stdio stream..
- Sascha
> > Is it really #1 module?? *sigh*
>
> Yup, by far.
You can find the current data here:
http://www.securityspace.com/s_survey/data/man.200301/apachemods.html
And for the archives, follow this link:
http://www.securityspace.com/s_survey/data/index.html
> Most reported bugs are
On Wednesday, February 5, 2003, at 08:02 AM, Jeff Trawick wrote:
Rasmus Lerdorf wrote:
Well, I stand by that. The filter API is a bloody mess. Something
which
should be simple and elegant has turned into this amazingly complex
tangle
of code that is nearly impossible to figure out.
What I
> Is it really #1 module?? *sigh*
Yup, by far.
> From my experience and that of some of programmers I know, PHP people are
> very reluctant to admit that they have bugs or fix their bugs. Usually
> they find it better to argue that you're the idiot and their code works
> (even when it does not)
On Wed, Feb 05, 2003 at 07:58:36PM -0800, Brandon Bell wrote:
> As an end user, I don't give a f*ck why it doesn't work! But I can tell
> you this -- until it does I have to stick with Apache 1.3.x. My sites and
> applications depend on PHP _way_ more then they depend on the nice new
> feature
Justin Erenkrantz wrote:
--On Wednesday, February 5, 2003 4:32 PM -0500 Bill Stoddard
<[EMAIL PROTECTED]> wrote:
1. Installing this filter for the duration of a connection. It is
still a protocol filter, but it lasts for the duration of the
connection. In order to handle pipelined connections, a
* Graham Leggett wrote:
> André Malo wrote:
>
>> from mod_proxy.c:302:
>>
>> static int proxy_needsdomain(request_rec *r, const char *url, const char
>> *domain)
>>
>> "url" is never used within that function. r->parsed_uri will be evaluated
>> instead. I'd consider this a bug and guess "url" sho
Brandon Bell wrote:
Okay guys, I have to weigh in here as a non-developer and add a
comment re
all of this back and forth discussion on whether PHP or Apache 2.0 is the
problem for why they don't work/play together properly.
As an end user, I don't give a f*ck why it doesn't work! But I can te
On Wed, 5 Feb 2003, Bill Stoddard wrote:
> More like -huge-. The threaded MPM makes a big (think nearly an order of
> magnitude) difference in scalability on AIX. I expect the same is true
> on Solaris. I also think we will see similar results on Linux with
> either of the new pthread libraries.
36 matches
Mail list logo
