You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Greg Stein <gs...@lyra.org> on 2003/02/05 03:31:10 UTC
story posted
A while back, I received an interview request for a story on Apache 2.0 and
its adoption. I think that it turned out quite well, and the author appeared
to give a fair treatment overall.
Check out the story at:
http://www.newsfactor.com/perl/story/20572.html
Some questions for thought: if we start banging out versions right and left,
then will people actually upgrade? Are we doomed to live with 1.3 forever?
Or do we have to stick with today's architecture to support binary
compatibility for N years?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: story posted
Posted by Bill Stoddard <bi...@wstoddard.com>.
Jim Jagielski wrote:
> At 6:31 PM -0800 2/4/03, Greg Stein wrote:
>
>>Some questions for thought: if we start banging out versions right and left,
>>then will people actually upgrade? Are we doomed to live with 1.3 forever?
>>Or do we have to stick with today's architecture to support binary
>>compatibility for N years?
>>
>
>
> Very nice. I think you hit the nail on the head. For many people,
> 1.3 is "good enough" and "has been working just fine" so why migrate?
> I think that the perception that 2.0 "hasn't been ready for Prime
> Time" is slowly changing, however. First of all, we've been good in
> stabilizing the 2.0 API. Crucial for module developers. Secondly,
> we see that result in more modules for 2.0.
Running a threaded mpm on Linux is just not interesting today. The
memory footprint of the server is reduced, but so is the performance
(requests per second). Even worse, with the current Linux pthread
implementation, the threaded MPM does not provide appreciably better
scalability (ability to support large numbers of concurrent clients)
than the prefork MPM. And just forget being able to efficiently use SMP
architectures with the threaded MPM.
However, all that will change dramatically with the introduction of the
new pthread libraries being developed by Redhat and IBM (may the best
implementation win :-). Starting with RH 8.1, the threaded MPM on Linux
should really start to shine.
Bill
html
Posted by fabio rohrich <ro...@yahoo.it>.
HI all,
is different to catch a normal .html file ( I mean not
server parsed) and one parsed (like .php)?
I can just read the file required from the request_rec
and elaborate it (if it's .html) or I need a filter to
catch the content (I'm sure I must do it for a parsed
file)?
Thanks!
______________________________________________________________________
Mio Yahoo!: personalizza Yahoo! come piace a te
http://it.yahoo.com/mail_it/foot/?http://it.my.yahoo.com/
Re: story posted
Posted by Jim Jagielski <ji...@jaguNET.com>.
At 6:31 PM -0800 2/4/03, Greg Stein wrote:
>
>Some questions for thought: if we start banging out versions right and left,
>then will people actually upgrade? Are we doomed to live with 1.3 forever?
>Or do we have to stick with today's architecture to support binary
>compatibility for N years?
>
Very nice. I think you hit the nail on the head. For many people,
1.3 is "good enough" and "has been working just fine" so why migrate?
I think that the perception that 2.0 "hasn't been ready for Prime
Time" is slowly changing, however. First of all, we've been good in
stabilizing the 2.0 API. Crucial for module developers. Secondly,
we see that result in more modules for 2.0.
The lack of PHP for 2.0 is also a problem, as you note. It's funny,
however, when the feelings in the PHP community indicate it's
because 2.0 is flawed/broken. When some of the prime PHP developers,
who also happen to be ASF members, say that 2.0 is stupid, and there's
no reason for anyway to possibly want to go from 1.3 to 2.0 so we're
not going to bother with 2.0-related stuff, it's a major handicap.
2.0 is not "just" different MPMs, as people imply when they say
"they have to stay with prefork for PHP, so why bother going with
2.0. Now once perchild makes it....".
Also, I think it's harder for new developers, or those who only
know 1.3, to pick up 2.0 over 1.3. There's a lot of stuff in there
that people need to wrap their brains around before they can play
and have fun. Still, the effort is worth it.
Basically, I see 1.3.x as almost maintenance mode only. Security and
bug fixes. The fact is that the future *is* 2.0. 1.3 has done
exceptionally well, better than we could have hoped. No, 1.3
isn't "broken" really, but 2.0 is better and it's where all the new,
interesting and fun stuff is happening.
--
===========================================================================
Jim Jagielski [|] jim@jaguNET.com [|] http://www.jaguNET.com/
"A society that will trade a little liberty for a little order
will lose both and deserve neither" - T.Jefferson
Re: story posted
Posted by Jeff Trawick <tr...@attglobal.net>.
Jeff Trawick wrote:
> You can also see text in our bug database from a prominent PHP developer
> saying that the filter API needs to be redone from scratch (my
> paraphrase). For the enthusiastic PHP users, such comments carry a lot
> of weight and imply that PHP isn't production ready with 2.0 not because
> nobody has made it a high priority to make PHP production ready but
> instead because there is something flawed about Apache 2.0.
Of course, there's a little bit of truth to everything :)
Somebody just closed a PR indicating that PHP was broken because it
checked the retcode of ap_pass_brigade() but needed to check c->aborted.
ISTR some discussion here to fix some issues with propagating errors
from filters so that, among other things, the retcode could be checked
to find out if this occurred.
Re: story posted
Posted by Bill Stoddard <bi...@wstoddard.com>.
Rasmus Lerdorf wrote:
>>You can also see text in our bug database from a prominent PHP developer
>>saying that the filter API needs to be redone from scratch (my
>>paraphrase). For the enthusiastic PHP users, such comments carry a lot
>>of weight and imply that PHP isn't production ready with 2.0 not because
>> nobody has made it a high priority to make PHP production ready but
>>instead because there is something flawed about Apache 2.0.
>
>
> 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.
>
> -Rasmus
>
I don't agree that "the filter API is a blooody mess", however I am
sympathetic to the emotion your expressing. Is 2.0 complex? yes. Does
it have a coherent design? IMHO, yes. Is it 'overengineered'? probably so.
My criticsm of the filter API is that the design tries to solve too many
problems and the resulting implementation is so complex that it creates
an unnecessarily high entry barrier for folks interested in doing 2.0
module development. Apache httpd is a protocol engine that should
provide useful services to folks building applications on top of it. The
value is in the applications that run on top of httpd, not httpd itself.
IMHO, application module developers are required to make an
unnecessarily large investment (in time and effort) in becoming 2.0
experts before they can get their applications running. PHP is horribly
complex, but PHP is where the value comes from so there is more
incentive for folks to become masters of PHP. The same is not true of
httpd 2.0.
IMHO, a large part of our continuing 2.0 development effort should be in
simplifying our current implementation while keeping the most important
services we provide to app developers.
Bill
Re: story posted
Posted by Cliff Woolley <jw...@virginia.edu>.
On Wed, 5 Feb 2003, Jeff Trawick wrote:
> What I think is useful information to people who want PHP+Apache-2.0 is:
>
> a) is PHP not production ready with Apache 2.0 because it was not high
> enough priority for PHP to be tested?
>
> b) is PHP not production ready with Apache 2.0 because Apache 2.0 must
> be fixed before such a thing is even possible?
>
> I see more comments implying b) than a). As such, it seems that anybody
> that wants to hack PHP to work better with 2.0 is wasting their time.
Having looked at it in depth personally, I'll say a strong (a). Aaron and
I had a good roadmap for how to get it all to work, and the only
modifications we needed to make were in Zend and PHP. The current PHP
Apache2 filter assumes that it can get a file handle and other silliness.
But we never had the time to actually fix it The Right Way, and the other
PHP people seemed to just want to say "b! b! it's Apache's fault" so we
got into this finger-pointing standoff and nobody ever fixed anything.
--Cliff
Re: story posted
Posted by Bill Stoddard <bi...@wstoddard.com>.
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 I hold this up as a trophy illustrating my earlier assertion
>> regarding overengineered 'solutions' to non existent problems.
>
>
> It doesn't really matter if it's in use by 1.3 today. If it's in
> use in 1.3 today then what use would 2.0 be?
>
> I've seen numerous bug reports stating this simple case. That to me
> validates this as a use case.
>
> -aaron
It is painfully obvious that the requirement is not important enough to
the PHP team (or the majority of PHP users) to cause them to hack their
code to enable it to work effectively as an Apache 2 filter. I honestly
don't blame them for the decision. If we care about our users, our
development time should be spent on the things that have the most
benefit to our users. Spending large amounts of time rewriting (and
destabilizing) code used by 100% of the PHP user base for the sole
purpose of providing a piddly capability that will only be used by an
infintesmal fraction of PHP users is not a good investment. IMHO.
On an aside... I bet if you let mod_php be a handler, you can still do
some pretty interesting things with output filters like mod_include. PHP
would own the file descriptor and could be told (via config) to insert
the SSI filter. Subrequests would be generated for the PHP tags and they
would be handled by the PHP handler. I don't see that this requirement
dictates PHP being a filter.
Bill
Re: story posted
Posted by Aaron Bannert <aa...@clove.org>.
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 trophy illustrating my earlier assertion
> regarding overengineered 'solutions' to non existent problems.
It doesn't really matter if it's in use by 1.3 today. If it's in
use in 1.3 today then what use would 2.0 be?
I've seen numerous bug reports stating this simple case. That to me
validates this as a use case.
-aaron
Re: story posted
Posted by Bill Stoddard <bi...@wstoddard.com>.
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 filter was a good idea to begin with. yea, it's more flexible but
>> that flexability comes at a high cost. And if no one is interested in
>> what that extra flexability gains you, then the only thing
>> accomplished is the code is more complex and bug prone. You know the
>> saying "if the only tool you have is a hammer, then all problems look
>> like nails"? Well for a while, apache 2.0 filters were 'the hammer'.
>> Hopefully that is changing now.
>
>
> I don't see how making it a handler will fix this problem.
> PHP will still want to read input bodies from the input
> filter chain.
>
> Also, I should point out that something as seemingly simple
> as an SSI file that includes multiple php scripts needs the
> filter stack.
>
> -aaron
So is that a popular configuration in use with 1.3 today? If not, then
I hold this up as a trophy illustrating my earlier assertion regarding
overengineered 'solutions' to non existent problems.
Bill
Re: story posted
Posted by Aaron Bannert <aa...@clove.org>.
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 to begin with. yea, it's more flexible but
> that flexability comes at a high cost. And if no one is interested in
> what that extra flexability gains you, then the only thing
> accomplished is the code is more complex and bug prone. You know the
> saying "if the only tool you have is a hammer, then all problems look
> like nails"? Well for a while, apache 2.0 filters were 'the hammer'.
> Hopefully that is changing now.
I don't see how making it a handler will fix this problem.
PHP will still want to read input bodies from the input
filter chain.
Also, I should point out that something as seemingly simple
as an SSI file that includes multiple php scripts needs the
filter stack.
-aaron
Re: story posted
Posted by Bill Stoddard <bi...@wstoddard.com>.
Sascha Schumann wrote:
>>a) is PHP not production ready with Apache 2.0 because it was not high
>>enough priority for PHP to be tested?
>
>
> The current Apache 2 support in PHP is based on filters only.
> That however is not well-supported by the scripting engine
> which prefers real file objects as input.
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 to begin with. yea, it's more flexible but that
flexability comes at a high cost. And if no one is interested in what
that extra flexability gains you, then the only thing accomplished is
the code is more complex and bug prone. You know the saying "if the only
tool you have is a hammer, then all problems look like nails"? Well for
a while, apache 2.0 filters were 'the hammer'. Hopefully that is
changing now.
>
> The next huge problem is thread-awareness of Unix libraries.
> There are still lots of issues with libraries which won't
> correctly in a threaded environment.
With the new Linux pthread implementations, folks will begin to see that
threaded servers will offer big boosts in scalability and we'll start
seeing more effort put into making popular PHP libraries thread safe.
That's my crystal ball.
Bill
Re: story posted
Posted by Rasmus Lerdorf <ra...@apache.org>.
> 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 gotten a number of TS bug reports, and what does Windows have to
do with it? Most Windows libraries are threadsafe to begin with. We are
not talking about TS issues in PHP here, we are talking about them in
libraries that we have no control over. Sometimes these are even
binary-only libraries. This is something that will eventually work itself
out as developers become more aware and threaded apps start becoming more
common on UNIX systems. But that doesn't change the fact that it is a
real problem for us today.
I would love to have a list of the known TS issues in the various
3rd-party libraries out there, and I did try to push that a bit with this:
http://httpd.apache.org/docs-2.0/developer/thread_safety.html
a while ago now. I was hoping for some more input here. We should be
able to get to the point where we can tell people that Apache2+PHP+"List
of safe extensions" is production-quality as long as they don't stray into
any of the extensions/3rd party libs on the unsafe/unknown list. Right
now that list unfortunately includes just about everything you can hook
into PHP.
-Rasmus
Re: story posted
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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. Personally I never thought implementing PHP as a filter was a good idea to begin with. yea, it's more flexible but that flexability comes at a high cost. And if no one is interested in what that extra flexability gains you, then the only thing accomplished is the code is more complex and bug prone. You know the saying "if the only tool you have is a hammer, then all problems look like nails"? Well for a while, apache 2.0 filters were 'the hammer'.
>>>Hopefully that is changing now.
>>
>>I don't see how making it a handler will fix this problem.
>>PHP will still want to read input bodies from the input
>>filter chain.
>>Also, I should point out that something as seemingly simple
>>as an SSI file that includes multiple php scripts needs the
>>filter stack.
>>-aaron
>
>So is that a popular configuration in use with 1.3 today? If not, then I hold this up as a trophy illustrating my earlier assertion regarding overengineered 'solutions' to non existent problems.
Exactly. Yes - a 'real' PHP filter would be terrific. In the meantime that
'filter' is broken, because it only accepts one file bucket.
The PHP Apache hackers should take a page from the jakarta connectors
flavors. If you want rock solid, use mod_jk. Experimental new efforts? You've
got mod_webapp and mod_jk2 (APR based - even for Apache 1.3).
Why toss the 'stable' and 'proven' php4apache, when you can simply port
it to 2.0 and provide PHP content today? Sure - when folks want svn backing
their PHP scripts you need a filter. But that should have been the "what we
are doing next" instead of treating Apache2 filters as the nail and trying to
be something it's not.
Now we have the worst of both worlds... php4apache2 can't filter non-fd based
buckets - so it's essentially broken for alternate script stores. But it doesn't
do the filtering very cleanly either.
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?
Bill
At 11:50 AM 2/6/2003, Aaron Bannert wrote:
>There is no such thing anymore as a handler in Apache 2.0, am I correct?
>Aren't the handler-like hooks that try to behave the same was as they did
>in 1.3 just implemented over output filters?
Ummm... look at mod_info or mod_status. Sure you can deal with
brigades instead of the ap_rwrite APIs, but that doesn't mean that
handlers don't exist. For that matter, what about mod_cgi?
php4apache2 is going through httpd's default handler and filtering that
result brigade. Simple enough for it to be its very own handler.
For example, all the XBitHack stuff really never belonged in a filter in
the first place. That flag should really only work for handlers that want
to respect it (and the core handler doesn't know how to e'x'ecute text
to the browser.)
Bill
Re: story posted
Posted by Sascha Schumann <sa...@schumann.cx>.
> So why not just do a handler-based PHP for 2.0, and work on other problems
> in the future. This is a silly family quarel that is making everyone look
> bad.
We are looking forward to your contributions. Please apply
for a CVS account here:
http://www.php.net/cvs-php.php
- Sascha
Re: story posted
Posted by Rasmus Lerdorf <ra...@apache.org>.
On Wed, 5 Feb 2003, 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
> > how it appears to the end-user at least.
>
> I don't buy that argument. Are you saying that if Apache 1.4 had been
> released with a couple extra modules but no threading or filters, then PHP
> would have stuck with 1.3 because it works "well enough"? No, I hope PHP
> would have updated to 1.4 to take advantage of the current development
> efforts. Those development efforts include not just a couple new modules
> (major ones like mod_ssl, mod_dav, mod_deflate, mod_auth_ldap, etc), but
> lots and lots of other enhancements (IPv6, PCRE, improved negotiation,
> better documentation, better non-unix support, many bug fixes, etc).
The reality is that people can do SSL, DAV, Gzip, auth_ldap and everything
else with 1.3. Things are a bit more coherent in 2.0 and from a design
perspective it all fits together in a nicer way, but an end user just
installs the appropriate package for 1.3 and it just works. The fact that
the guy who rolled the package had a nightmare job to make it seamless is
of no real concern to the end user.
Our bread and butter here are the Linux and FreeBSD web servers out there.
They do not run ipv6, they don't care about Windows and they certainly
don't read documentation. What are we offering them?
> So why not just do a handler-based PHP for 2.0, and work on other problems
> in the future. This is a silly family quarel that is making everyone look
> bad.
Go for it. You sound motivated. http://www.php.net/cvs-php.php is where
you sign up for a CVS account. I will make sure you, or anyone else here
interested in helping out gets a CVS account promptly.
-Rasmus
Re: story posted
Posted by Ian Holsman <li...@holsman.net>.
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 the actually usefullness
of php in general in a apache2 model.
unless we can make php not use TLS and use request-specific data.
(or have php pass a index into TLS so that each function knows what
request it is actually parsing.)
the other workaround to this I guess is to parse the entire php file
in one shot, and then not allow the filter chain to get it's hand on a
uncompleted php request, which would force php to serialize across the
thread.
so .. making this into a handler would require 2 things.
1. only grabbing post data once, (and for multiple php requests in the
same page the first one gets it, and the others have undefined behavior)
2a. forcing php to evaluate the entire php script before moving onto the
next one. (ie.. don't pass any data down the filter chain until php is
done with the lot)
or
2b. modifiy php to not use TLS and passing it a handle to it's local data
making it re-entrant safe.
2b is a better solution, but I think 2a could be doable faster.
is this plausable?
Re: story posted
Posted by Sascha Schumann <sa...@schumann.cx>.
> 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
Re: story posted
Posted by Bill Stoddard <bi...@wstoddard.com>.
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 multiple php scripts
> (same as how CGI does).
Just came to the same conclusion in another response.
>
> my major concern is a php-script creating subrequests which include other
> php-scripts. forcing php to be re-entrant.
>
> is php re-entrant? or does it use globals/thread specific storage. if it
> does than php can not be used in a subrequest.
Good question and I don't know the answer.
Bill
Re: story posted
Posted by Ian Holsman <li...@holsman.net>.
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 scripts
(same as how CGI does).
my major concern is a php-script creating subrequests which include other
php-scripts. forcing php to be re-entrant.
is php re-entrant? or does it use globals/thread specific storage. if it
does than php can not be used in a subrequest.
>
> Bill
Re: story posted
Posted by Sascha Schumann <sa...@schumann.cx>.
> 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.)
Using temporary files is the only way to deal with it once
you reach a certain threshhold. I implemented this for PHP's
thttpd SAPI a few weeks ago. It's really simple.
- Sascha
Re: story posted
Posted by Aaron Bannert <aa...@clove.org>.
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
> are there to read POST'ed data. I would think it's not too terribly
> difficult to port 1.3 mod_php to 2.0 using the exact same handler
> model.
>
> Of course you still won't be able to embed php scripts in SSI tags
> (w/o doing unnatural things) but who really cares?
I just looked at mod_cgi, and lo and behold it uses input and output
filters
for reading POST bodies and generating output, even though it's
implemented in
the handler hook. If you see any other handlers/generators that consume
input
bodies and use the APIs you're talking about, please point them out.
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
Re: story posted
Posted by Bill Stoddard <bi...@wstoddard.com>.
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 that if Apache 1.4 had been
>> released with a couple extra modules but no threading or filters, then
>> PHP
>> would have stuck with 1.3 because it works "well enough"? No, I hope PHP
>> would have updated to 1.4 to take advantage of the current development
>> efforts. Those development efforts include not just a couple new modules
>> (major ones like mod_ssl, mod_dav, mod_deflate, mod_auth_ldap, etc), but
>> lots and lots of other enhancements (IPv6, PCRE, improved negotiation,
>> better documentation, better non-unix support, many bug fixes, etc).
>>
>> So why not just do a handler-based PHP for 2.0, and work on other
>> problems
>> in the future. This is a silly family quarel that is making everyone
>> look
>> bad.
>
>
> There is no such thing anymore as a handler in Apache 2.0, am I correct?
> Aren't the handler-like hooks that try to behave the same was as they did
> in 1.3 just implemented over output filters?
>
> -aaron
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
are there to read POST'ed data. I would think it's not too terribly
difficult to port 1.3 mod_php to 2.0 using the exact same handler model.
Of course you still won't be able to embed php scripts in SSI tags (w/o
doing unnatural things) but who really cares?
Bill
Re: story posted
Posted by Jeff Trawick <tr...@attglobal.net>.
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 filter chain in brigades
Re: story posted
Posted by Aaron Bannert <aa...@clove.org>.
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
>> how it appears to the end-user at least.
>
> I don't buy that argument. Are you saying that if Apache 1.4 had been
> released with a couple extra modules but no threading or filters, then
> PHP
> would have stuck with 1.3 because it works "well enough"? No, I hope
> PHP
> would have updated to 1.4 to take advantage of the current development
> efforts. Those development efforts include not just a couple new
> modules
> (major ones like mod_ssl, mod_dav, mod_deflate, mod_auth_ldap, etc),
> but
> lots and lots of other enhancements (IPv6, PCRE, improved negotiation,
> better documentation, better non-unix support, many bug fixes, etc).
>
> So why not just do a handler-based PHP for 2.0, and work on other
> problems
> in the future. This is a silly family quarel that is making everyone
> look
> bad.
There is no such thing anymore as a handler in Apache 2.0, am I correct?
Aren't the handler-like hooks that try to behave the same was as they
did
in 1.3 just implemented over output filters?
-aaron
Re: story posted
Posted by Joshua Slive <jo...@slive.ca>.
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
> how it appears to the end-user at least.
I don't buy that argument. Are you saying that if Apache 1.4 had been
released with a couple extra modules but no threading or filters, then PHP
would have stuck with 1.3 because it works "well enough"? No, I hope PHP
would have updated to 1.4 to take advantage of the current development
efforts. Those development efforts include not just a couple new modules
(major ones like mod_ssl, mod_dav, mod_deflate, mod_auth_ldap, etc), but
lots and lots of other enhancements (IPv6, PCRE, improved negotiation,
better documentation, better non-unix support, many bug fixes, etc).
So why not just do a handler-based PHP for 2.0, and work on other problems
in the future. This is a silly family quarel that is making everyone look
bad.
Joshua.
Re: story posted
Posted by Sascha Schumann <sa...@schumann.cx>.
> a) is PHP not production ready with Apache 2.0 because it was not high
> enough priority for PHP to be tested?
The current Apache 2 support in PHP is based on filters only.
That however is not well-supported by the scripting engine
which prefers real file objects as input.
The next huge problem is thread-awareness of Unix libraries.
There are still lots of issues with libraries which won't
correctly in a threaded environment.
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.
- Sascha
Re: story posted
Posted by Aaron Bannert <aa...@clove.org>.
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 think is useful information to people who want PHP+Apache-2.0
> is:
>
> a) is PHP not production ready with Apache 2.0 because it was not high
> enough priority for PHP to be tested?
>
> or
>
> b) is PHP not production ready with Apache 2.0 because Apache 2.0 must
> be fixed before such a thing is even possible?
>
> I see more comments implying b) than a). As such, it seems that
> anybody that wants to hack PHP to work better with 2.0 is wasting
> their time.
I'm still catching up on email, so apologies if someone has already
replied to this...
There are two basic problems in getting PHP to work with Apache 2:
1) PHP wants to pull data (both POST bodies and php scripts);
but Apache 2 output filters want to push data. Buffering the
entire output stream is not feasible.
2) PHP depends on many third party libraries, many of which are
neither reentrant nor threadsafe.
-aaron
Re: story posted
Posted by Rasmus Lerdorf <ra...@apache.org>.
> What I think is useful information to people who want PHP+Apache-2.0 is:
>
> a) is PHP not production ready with Apache 2.0 because it was not high
> enough priority for PHP to be tested?
That is a big part of it. The fact that the thread-safety of many
third-party libraries that can be linked into a PHP (or mod_perl) setup is
questionable at best has not made us rush out to support Apache 2. If
there was some compelling end-user feature that people clamoured for, it
would be a different story, but as it is, Apache2 is just a headache for
us. People would have to run in prefork mode so neither the architecture
nor the performance are compelling arguments to switch for the end user.
>From our perspective, the additional effort required to field all these
bug reports about Apache2+PHP+Worker doing weird and wonderful things
makes it quite a PITA and we thus push people toward 1.3. Thread-safety
issues are hard to debug and causes a lot of indecipherable and mostly
useless bug reports. RedHat is currently my least favourite company due
to the added support email load they have caused me. And yes, I know,
"Just tell them to use prefork". But with Apache-1.3 there is no Worker
mpm and most of the time when you ask a user which mpm they are using, the
response is a big fat, "duh, mpm?".
> b) is PHP not production ready with Apache 2.0 because Apache 2.0 must
> be fixed before such a thing is even possible?
>
> I see more comments implying b) than a). As such, it seems that anybody
> that wants to hack PHP to work better with 2.0 is wasting their time.
I don't think b) outweighs a) here. The issues in a) is the demotivator
and b) is just the final nail in the coffin. If we were motivated enough
we would work through the API stuff and figure out how to better get PHP
aligned to the current filter approach. It's not like the Apache 1.3 API
is super clean either. We just know it pretty well and PHP was built up
around it almost from the beginning.
I guess the real issue here is not even the end users as much as the
developers themselves. Apache 1.3 was historically written by webmasters
for webmasters running realworld servers. When/if Apache2 reaches a point
where we, as developers, switch to using it for ourselves, PHP support
will arrive in full force. As it is, it is just one server on the long
list of servers somewhat supported by PHP.
-Rasmus
Re: story posted
Posted by Jeff Trawick <tr...@attglobal.net>.
Rasmus Lerdorf wrote:
> >You can also see text in our bug database from a prominent PHP developer
> >saying that the filter API needs to be redone from scratch (my
> >paraphrase). For the enthusiastic PHP users, such comments carry a lot
> >of weight and imply that PHP isn't production ready with 2.0 not because
> > nobody has made it a high priority to make PHP production ready but
> >instead because there is something flawed about Apache 2.0.
>
>
> 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.
>
> -Rasmus
What I think is useful information to people who want PHP+Apache-2.0 is:
a) is PHP not production ready with Apache 2.0 because it was not high
enough priority for PHP to be tested?
or
b) is PHP not production ready with Apache 2.0 because Apache 2.0 must
be fixed before such a thing is even possible?
I see more comments implying b) than a). As such, it seems that anybody
that wants to hack PHP to work better with 2.0 is wasting their time.
Re: story posted
Posted by Rasmus Lerdorf <ra...@apache.org>.
> You can also see text in our bug database from a prominent PHP developer
> saying that the filter API needs to be redone from scratch (my
> paraphrase). For the enthusiastic PHP users, such comments carry a lot
> of weight and imply that PHP isn't production ready with 2.0 not because
> nobody has made it a high priority to make PHP production ready but
> instead because there is something flawed about Apache 2.0.
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.
-Rasmus
Re: story posted
Posted by Jeff Trawick <tr...@attglobal.net>.
Joe Orton wrote:
> On Tue, Feb 04, 2003 at 06:31:10PM -0800, Greg Stein wrote:
> ...
>
> >Some questions for thought: if we start banging out versions right
> and left,
> >then will people actually upgrade? Are we doomed to live with 1.3
> forever?
> >Or do we have to stick with today's architecture to support binary
> >compatibility for N years?
>
>
> PHP has been one of the main problems we've seen in acceptance: people
> are scared off 2.0 because the PHP documentation has a big warning
> saying "don't use PHP with 2.0 on production servers".
You can also see text in our bug database from a prominent PHP developer
saying that the filter API needs to be redone from scratch (my
paraphrase). For the enthusiastic PHP users, such comments carry a lot
of weight and imply that PHP isn't production ready with 2.0 not because
nobody has made it a high priority to make PHP production ready but
instead because there is something flawed about Apache 2.0.
Re: story posted
Posted by Joe Orton <jo...@redhat.com>.
On Tue, Feb 04, 2003 at 06:31:10PM -0800, Greg Stein wrote:
...
> Some questions for thought: if we start banging out versions right and left,
> then will people actually upgrade? Are we doomed to live with 1.3 forever?
> Or do we have to stick with today's architecture to support binary
> compatibility for N years?
PHP has been one of the main problems we've seen in acceptance: people
are scared off 2.0 because the PHP documentation has a big warning
saying "don't use PHP with 2.0 on production servers".
joe
Re: story posted
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, February 5, 2003 10:09 AM -0600 "William A. Rowe,
Jr." <wr...@rowe-clan.net> wrote:
> This is a bug in the way Apache autoconf's... OpenSSL and OpenLDAP
> should never be linked to the core... they should have been
> detected and added only to the modules/ssl and modules/ldap
> makefiles' CFLAGS/LDFLAGS.
The majority of Unix platforms don't allow inheriting LDFLAGS from
DSOs. Therefore, the core must dynamically link against OpenSSL and
OpenLDAP not the modules. The run-time linker gets its search paths
from the executable not the DSOs.
So, I don't think you can do that portably.
> Let's expect to fix that before releasing 2.2. And maybe consider
> always enabling APR thread support while we are at it.
APR thread support is always enabled if the platform has it (not sure
why you think it doesn't).
We've disabled it by default on FreeBSD because we know the thread
libraries still has subtle quirks (user is free to override us by
passing --enable-threads). We're trying to find someone with 5.0 and
see if it is fixed. I believe Tony Finch has hinted that 5.1 might
have the real fixes we need for FreeBSD. -- justin
Re: story posted
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 09:17 AM 2/5/2003, Jess M. Holle wrote:
>Graham Leggett wrote:
>
>>Greg Stein wrote:
>>
>>>Some questions for thought: if we start banging out versions right and left,
>>>then will people actually upgrade? Are we doomed to live with 1.3 forever?
>>>Or do we have to stick with today's architecture to support binary
>>>compatibility for N years?
>>
>>
>>I think OS distributions will play a large role in this. When the Solaris / Redhat / Suse / IBM / Whoever people start shipping v2.0 with their OS'es (which has already started happening in the case of redhat) adoption will be quite quick.
>>
>>In addition, apache v2.0 comes with SSL + LDAP built in, where v1.3 did not - this will probably give people more reason to use it.
>
>Built in only to a point. The standard distribution does not contain either of these. What's more, you have to rebuild the core (or APR at least) and link these in to have either of these.
>
>Sorry, but this hits a nerve -- with Apache 1.3 we had 2 major sets of potentially incompatible binaries - EAPI and non-EAPI. With Apache 2.0 we have 2 x 2 (=4), i.e. SSL and non-SSL enabled and LDAP and non-LDAP enabled and permutations thereof.
<fudbuster method="dispell">
Sorry but that's a pretty gross misstatement.
EAPI is an extension to the core server. It necessarily breaks binary
compatibility between modules (in a sometimes insignificant way - that's
for you - the module author - to determine for your module.) And you forgot
the third flavor, ApacheSSL, which also breaks compatibility. There is really
no reconciling a server built for SSL or without SSL with Apache 1.3.
With Apache 2.0, all of the hooks are there, all of the time. The core server
always remains compatible with all compiled modules, regardless of how that
core server was built (with or without SSL, with or without LDAP), with one
significant caviat. But SSL and LDAP have nothing to do with it, I have many
builds of mod_ssl alternately using OpenSSL and RSA's toolkit, and two LDAP
builds I'm working with, using both Netscape SDK and the Win32 API. The
point is I can load, or not load, any of those modules (although not two different
builds of the very same module.)
No, SSL and LDAP questions are FUD, that's for the RPM'er to determine.
(One caveat follows at the end.)
The real issue is how APR is built underneath Apache, and to a lesser degree
(because I consider the following a bug) how Apache made choices based on
APR's configuration. In other words, if APR is built without threading support,
you can't load a module that requires threading (even if Apache is running
prefork and the module does it's own thread pool magic.) If APR is built with
threading support, you can use prefork, worker or any other module. There are
some other more subtle distinctions in how APR is configured v.s. how it can
be used.
Those bugs, modules making choices based on APR build flags is usually
bad design. It's trivial to query the MPM to find out if the server is really using
multiple threads v.s. a single worker thread in each process. Testing the
APR_HAS_THREADS macro is usually the wrong choice for module authors.
But with good design, the author can ask APR if it supports or is using any
of a number of features at runtime, and can ask Apache what the profile of
the currently running MPM is (see mod_status and mod_info to get the
general idea.) And even across modules, optional functions allow one module
to publish functions that other modules may use (similar to EAPI, but much
more flexible and robust.) The best example here is mod_log_config, which
allows any module to add %{}n translations for a given character code.
The well designed module inquires of the optional function or registered
function, and if it can survive without finding that function, it should go
merrily on it's way without those specific features enabled.
So the simple fact is that with the 2.2 release we need to consider what
we advise module authors to code to ensure portability (and follow our own
advise), and we will finally eliminate the last vestiges of the EAPI problem.
</fudbuster>
>Is there any way we can stop linking LDAP and SSL into the core to use them, e.g. have mod_ssl be the only thing linking to OpenSSL and mod_ldap and/or mod_auth_ldap be the only modules linking to LDAP, i.e. so we can have one big mess of interchangeable binaries -- at least for a given MPM worker... [I have to believe this will settle down to worker for UNIX and the Windows worker for Windows for the 90+% case for a while anyway.]
This is a bug in the way Apache autoconf's... OpenSSL and OpenLDAP should
never be linked to the core... they should have been detected and added only
to the modules/ssl and modules/ldap makefiles' CFLAGS/LDFLAGS.
Let's expect to fix that before releasing 2.2. And maybe consider always
enabling APR thread support while we are at it.
Bill
Re: story posted
Posted by "Jess M. Holle" <je...@ptc.com>.
Graham Leggett wrote:
> Greg Stein wrote:
>
>> Some questions for thought: if we start banging out versions right
>> and left,
>> then will people actually upgrade? Are we doomed to live with 1.3
>> forever?
>> Or do we have to stick with today's architecture to support binary
>> compatibility for N years?
>
>
> I think OS distributions will play a large role in this. When the
> Solaris / Redhat / Suse / IBM / Whoever people start shipping v2.0
> with their OS'es (which has already started happening in the case of
> redhat) adoption will be quite quick.
>
> In addition, apache v2.0 comes with SSL + LDAP built in, where v1.3
> did not - this will probably give people more reason to use it.
Built in only to a point. The standard distribution does not contain
either of these. What's more, you have to rebuild the core (or APR at
least) and link these in to have either of these.
Sorry, but this hits a nerve -- with Apache 1.3 we had 2 major sets of
potentially incompatible binaries - EAPI and non-EAPI. With Apache 2.0
we have 2 x 2 (=4), i.e. SSL and non-SSL enabled and LDAP and non-LDAP
enabled and permutations thereof.
Is there any way we can stop linking LDAP and SSL into the core to use
them, e.g. have mod_ssl be the only thing linking to OpenSSL and
mod_ldap and/or mod_auth_ldap be the only modules linking to LDAP, i.e.
so we can have one big mess of interchangeable binaries -- at least for
a given MPM worker... [I have to believe this will settle down to
worker for UNIX and the Windows worker for Windows for the 90+% case for
a while anyway.]
--
Jess Holle
Re: story posted
Posted by Graham Leggett <mi...@sharp.fm>.
Greg Stein wrote:
> Some questions for thought: if we start banging out versions right and left,
> then will people actually upgrade? Are we doomed to live with 1.3 forever?
> Or do we have to stick with today's architecture to support binary
> compatibility for N years?
I think OS distributions will play a large role in this. When the
Solaris / Redhat / Suse / IBM / Whoever people start shipping v2.0 with
their OS'es (which has already started happening in the case of redhat)
adoption will be quite quick.
In addition, apache v2.0 comes with SSL + LDAP built in, where v1.3 did
not - this will probably give people more reason to use it.
Regards,
Graham
--
-----------------------------------------
minfrin@sharp.fm "There's a moon
over Bourbon Street
tonight..."
Re: story posted
Posted by Jim Jagielski <ji...@jaguNET.com>.
At 10:25 AM -0500 2/5/03, Ben Hyde wrote:
>
>There is a fun transition in progress. The 1.3 crowd had a lot of people who were very passionate about operational focus - i.e. apache embedded as a component in a large complex system of other junk (people, business, middleware, whatever). Overtime that assured that it aligned nicely with the needs of the people that run real websites.
>
>The 2.0 crowd is more inward looking, very expert in how to engineer the web server engine. When the 2.0 enterprise emerged a lot of 1.3 folks wandered off, the refactoring work wasn't what they were passionate about. As 2.0 is adopted by the operational crowd we will see more contributors with those passions returning. They will help to make adoption and upgrade easier. They will help to polish the beast into something that is fits their needs better and better.
>
Ben makes an extremely good point above. Not to be a fuddy-duddy, but
when developing the 0.x -> 1.3 releases, it was a lot about "Why do
I, as a web adminstrator/user want and need" and we'd add that in.
Just about every developer was also someone who depended on Apache.
When 2.0 started, and up until "recently", the majority of the effort
was getting to a point where you had a server that ran well enough
that you could consider adding real-world functional needs. Personally,
I think the time and effort spent on getting the engine foundation right
and featureful made sense, since it provides a much better platform
for the operational aspects. Some things that someone would want to
do, operationally, was darn near impossible with 1.3, but quite doable
with 2.0.
--
===========================================================================
Jim Jagielski [|] jim@jaguNET.com [|] http://www.jaguNET.com/
"A society that will trade a little liberty for a little order
will lose both and deserve neither" - T.Jefferson
Re: story posted
Posted by Ben Hyde <bh...@pobox.com>.
Putting on my PR hat - we could do a better job of getting out 'talking
points' ducks in line. Like Greg says that kind of marketing outreach
is not us. All the points Greg touched on in that article should be in
our talking points and there are more!
There should be 3-5 points we make every-time about why 2.0 is the
cat's pajamas.
Unlike a commercial vendor we aren't caught between the rock and a hard
place that forces vendors to trade off forcing users to go thru upgrade
hell to assure they can pull down some more revenue. We get to build
what we hope is a better thing and if it is people will migrate to it.
We should not ever complain that other large constituencies haven't
'gotten with the program.' We should always talk about how it's hard
for these large constituencies to move, to reengineer. Boy we have
sympathy for it. We work with them. We respect them.
Unlike a commercial vendor, we do not have an end-of-life plan for 1.3.
We do no intend to have one. As long as people want to work on it,
more power to them! Nobody should every be embarrassed that they
haven't switched to 2.0. Try it, you'll like it.
There is a fun transition in progress. The 1.3 crowd had a lot of
people who were very passionate about operational focus - i.e. apache
embedded as a component in a large complex system of other junk
(people, business, middleware, whatever). Overtime that assured that
it aligned nicely with the needs of the people that run real websites.
The 2.0 crowd is more inward looking, very expert in how to engineer
the web server engine. When the 2.0 enterprise emerged a lot of 1.3
folks wandered off, the refactoring work wasn't what they were
passionate about. As 2.0 is adopted by the operational crowd we will
see more contributors with those passions returning. They will help to
make adoption and upgrade easier. They will help to polish the beast
into something that is fits their needs better and better.
Some of the rough going around the heavy weight complementary products
(the middleware, the platforms, the larger sites, etc) is tied to that,
or at least analogous to that.
- ben
"Upgrade - the most frightening word in modern computing."
On Tuesday, February 4, 2003, at 09:31 PM, Greg Stein wrote:
> A while back, I received an interview request for a story on Apache
> 2.0 and
> its adoption. I think that it turned out quite well, and the author
> appeared
> to give a fair treatment overall.
>
> Check out the story at:
>
> http://www.newsfactor.com/perl/story/20572.html
>
>
> Some questions for thought: if we start banging out versions right and
> left,
> then will people actually upgrade? Are we doomed to live with 1.3
> forever?
> Or do we have to stick with today's architecture to support binary
> compatibility for N years?
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
>