Sebastian Nohn wrote:
I fear that many users of Apache would actually turn off the
Server header for no or for the wrong reasons (which may "harm" our
market share), and therefore I'm -1 on including this patch.
It would not change apaches market share. If you are talking about
netcraft (and si
Jim Jagielski wrote:
Please test and vote on releasing Apache httpd 1.3.36
Download from:
http://httpd.apache.org/dev/dist/
Changes:
http://httpd.apache.org/dev/dist/CHANGES_1.3
Works ok on Debian-unstable with the standard set of Debian patches
applied. It might be time to roll in
William A. Rowe, Jr. wrote:
Joseph Dane wrote:
Joshua Slive <[EMAIL PROTECTED]> writes:
In very early versions of the Apache HTTP Server, the
AddType directive was also used to activate
special server-side processing (such as mod_include
or PHP) by assigning "magic" MIME types to files. This
Enrico Weigelt wrote:
> Hi folks,
>
>
> I'd like to stop httpd from detaching itself, so I can start
> it from init.
>
> How can this be done ?
httpd -X if you want a single non-forking non-detached process
httpd -F if you just want the main process to be non-detached and still
hav
Paul Querna wrote:
> So, here is my short-list-made-up-this-afternoon of things I would like
> to look at doing after 2.2 is branched/released as GA. I welcome
> additions too.
>
> 1) Eliminate the HTTP in HTTPD. I would like to be able to compile
> httpd with --disable-http. Currently the 'htt
Paul Querna wrote:
> The Problem:
>
> We do not know what protocol will be used to handle a connection until
> runtime. We currently cannot determine this at startup.
>
>
> This results in:
>
> Primary: Accept Filters and TCP_DEFFER_ACCEPT are currently not used
> correctly. The 'httpready' a
Paul Querna wrote:
In real life, I don't believe this is detrimental, since if the
accf_http filter sees data it doesn't understand, it acts just like
accf_data -- and mod_ssl reads the data just like normal.
Hrm.. I am not sure I am convinced of that based on what I have seen on
some misconfigur
Paul Querna wrote:
Rasmus Lerdorf wrote:
Ivan Barrera A. wrote:
I haven't been able to enable acceptfilters on linux. Where can i get a
howto or some info ?
Sorry, I led you slightly astray. SO_ACCEPTFILTER is for FreeBSD. In
Linux the option is referred to as TCP_DEFER_ACCEPT and I
Nick Kew wrote:
I have some recollection of that problem, but not the solution. It's
actually somewhat topical for my client right now. You and Paul have
told us about FreeBSD and Linux; is there also a Solaris equivalent?
(probably not required as they're gradually upgrading it to Linux,
but wou
Ivan Barrera A. wrote:
I haven't been able to enable acceptfilters on linux. Where can i get a
howto or some info ?
Sorry, I led you slightly astray. SO_ACCEPTFILTER is for FreeBSD. In
Linux the option is referred to as TCP_DEFER_ACCEPT and I don't actually
think this is implemented in the publ
Nick Kew wrote:
Turn on accept filtering and this problem goes away. Or at least it
moves to be a kernel-level issue instead of an Apache one.
How does that work with large requests? Doesn't the whole principle
leave you the choice of just moving the DOS attack or breaking
pipelining?
You mean th
Ivan Barrera A. wrote:
How about linux ? how about Windows ? how about (put your favorite OS
here) ?
Linux has SO_ACCEPTFILTER which doesn't trigger the accept until there
is data, so accept filtering works on Linux too. Windows? No idea.
But I bet an Apache DoS would be the least of your worri
Ivan Barrera A. wrote:
It doesn't.
How so? With accept filtering, simply opening up the socket doesn't
trigger Apache in any way, so how is Apache DoS'ed in that case? And
under FreeBSD with the httpready filter you can trickle really slow
requests over the socket and Apache still won't see an
Turn on accept filtering and this problem goes away. Or at least it
moves to be a kernel-level issue instead of an Apache one.
-Rasmus
Ivan Barrera A. wrote:
Hi...
I'm still fighting (probably for a lost cause.. but my boss ask me to
do this).
In the socket activity there are some troubles dea
William A. Rowe, Jr. wrote:
For anyone who wants to argue that this is a PHP-caused anomaly, note also
http://www.securityspace.com/s_survey/data/man.200501/apachemods.html
-10% followed by +11% the following month:
http://www.securityspace.com/s_survey/data/man.200502/apachemods.html
Big swings li
Paul A. Houle wrote:
On Linux I've done some benchmarking and found that worker isn't
any faster than prefork at serving static pages. (Is it any different
on other platforms, such as Solaris?) In principle you might save RAM
by running prefork, but in this day and age you can fit 16
On Wed, 12 Jan 2005, Paul Querna wrote:
> - The entire AcceptFilter/TCP_DEFER_ACCEPT code needs to be refactored
> to properly work with different protocols.
Has anybody here had a look at implementing httpready for Linux or is the
'just use Tux' camp still winning this one? I had a quick look, b
Cliff Woolley wrote:
It might be. We've considered having it be configurable before. There
are just a lot of implications in changing the value; for example, it
affects the memory footprint of the server, it affects how much data gets
read in to memory per read() call on a file bucket (which migh
Cliff Woolley wrote:
On Fri, 7 Jan 2005, Rasmus Lerdorf wrote:
Why is it hardcoded to be 8000? It would seem like you could easily be
unlucky and just miss the cutoff and end up with a 6000 byte heap bucket
followed by a 3000 byte transient bucket, for example, as a result of 3
3000 byte
Why is it hardcoded to be 8000? It would seem like you could easily be
unlucky and just miss the cutoff and end up with a 6000 byte heap bucket
followed by a 3000 byte transient bucket, for example, as a result of 3
3000 byte ap_rwrites. For that particular case it might be quite
beneficial t
On Thu, 30 Dec 2004, Paul Querna wrote:
> Rasmus Lerdorf wrote:
> [snip]
> >>Hint: document root is a configuration value used *by default* in
> >>filename translation. Any module can implement its own translation
> >>hook, but trying to change a core configurat
On Fri, 31 Dec 2004, Nick Kew wrote:
> On Thu, 30 Dec 2004, Rasmus Lerdorf wrote:
>
> > Nobody is saying anything about doing it anywhere within a request.
>
> Huh? What are you smoking?
>
> > obviously you can't change the doc_root after the fact, but I see no
&g
On Fri, 31 Dec 2004, Nick Kew wrote:
> On Thu, 30 Dec 2004, Paul Querna wrote:
>
> > > Just sets the root server's docroot then now. Not being able able to
> > > manipulate the document_root is a rather severe limitation as far as I am
> > > concerned.
> >
> > I agree. But to fix it properly, we n
On Thu, 30 Dec 2004, Paul Querna wrote:
> It is impossible with the current way virtual hosts and document roots
> are handled.
I guess doing it per-conf Apache1-style, as in:
conf = ap_get_module_config()
conf->ap_document_root = ...;
Just sets the root server's docroot then now. Not being
On Wed, 8 Sep 2004, [ISO-8859-15] André Malo wrote:
> Actually I'm talking about the two proposals on the top. If you are
> interested in backport voting, you need to touch the STATUS file anyway and
> should follow the commits there.
I'd still suggest posting them here. Until the lawyers here fi
On Wed, 8 Sep 2004, [ISO-8859-15] André Malo wrote:
> * Jim Jagielski <[EMAIL PROTECTED]> wrote:
>
> > In general, people don't look for 1.3 patches in the 2.0 STATUS file
> > and vice-versa :)
>
> As far as I can see, the current way to make changes is 2.1 -> 2.0 -> 1.3.
> So it makes sense for m
On Tue, 7 Sep 2004, [ISO-8859-15] André Malo wrote:
> * Jim Jagielski <[EMAIL PROTECTED]> wrote:
>
> > I'd like to propose a 1.3.32 release with a T&R either late this
> > week or early next.
>
> Sounds good.
> Though I'd like to point to the 2.0 status file, where a bugfix (to 2.0
> and 1.3) is wa
On Tue, 7 Sep 2004, Geoffrey Young wrote:
> the attached patch is a direct port of the logic from 2.0 to 1.3. thoughts
> or insights on why this wouldn't be a good idea for 1.3 or other feedback
> appreciated.
Seems like a good idea to me.
-Rasmus
I had used the same approach but just had it external. Putting it inside
is a better idea. I still think it is dumb that this isn't called at a
much earlier stage, but changing that is more likely to break stuff than
this approach.
-Rasmus
On Sat, 28 Aug 2004, Jim Jagielski wrote:
> Here is, I
On Fri, 27 Aug 2004 [EMAIL PROTECTED] wrote:
>/*
> + * We need to ensure that r->connection->keepalive is valid in
> + * order to determine if we can discard the request body below.
> + */
> +ap_set_keepalive(r);
I realize you probably just took my wording there, bu
Yeah, I am not keen on the notes table approach either. My original patch
to fix this didn't do that. Not that my patch was great either.
The problem with calling ap_set_keepalive() multiple times is that the
function doesn't just set the keepalive flag, it also increments the
connection's keepa
On Fri, 20 Aug 2004, Jim Jagielski wrote:
> I'm reviewing this... I'm mostly investigating whether
> the check for keepalive!=1 before calling ap_set_keepalive
> in ap_send_http_header and ap_send_error_response is
> too ap_die() specific. It seems to me that
> ap_set_keepalive should be smarter in
.
*/
On Tue, 6 Jul 2004, Jim Jagielski wrote:
> Yes, we do, and we're still waiting for a patch. However,
> I can't see us delaying 1.3.32 for an "unreasonable"
> amount of time.
>
> On Jul 5, 2004, at 10:54 AM, Rasmus Lerdorf wrote:
>
> > W
We still have that outstanding issue of conn->keepalive being bogus in
ap_die() because it hasn't been set yet and thus we can't discard the
request body in situations where we really need to. See my previous long
explanation of that problem.
-Rasmus
On Sat, 3 Jul 2004, Jim Jagielski wrote:
> L
On Wed, 9 Jun 2004, Jim Jagielski wrote:
> On Jun 9, 2004, at 3:24 PM, Rasmus Lerdorf wrote:
> > I guess what we are agreeing on here is that the logic that sets
> > keepalive
> > to 0 is faulty and that is probably where the real fix lies.
> yeah... it's pr
On Wed, 9 Jun 2004, Joe Orton wrote:
> When ap_die() is called, ap_set_keepalive() has not been called, and
> r->connection->keepalive is set to 0, as it was initialized so.
>
> The last thing ap_die does is call ap_send_error_response, which calls
> ap_send_http_header, which calls ap_set_keepali
On Wed, 9 Jun 2004, Joe Orton wrote:
> On Wed, Jun 09, 2004 at 09:21:07AM -0700, Rasmus Lerdorf wrote:
> > Don't see that anywhere. Either eaten by spam filters or a gerbil.
> >
> > Anyway, I don't understand why this would have broken mod_dav. If mod_dav
>
#x27;s the one you use to provide HTTPD related
> patches).
>
> On Jun 8, 2004, at 5:10 PM, Rasmus Lerdorf wrote:
>
> > Uh, I never received anything on this. Did you actually send me
> > something? I'll have a look at addressing this issue. Releasing
> > 1.3.32
&
Uh, I never received anything on this. Did you actually send me
something? I'll have a look at addressing this issue. Releasing 1.3.32
without this fix would be a nasty backwards step. The original problem
this fixes is serious.
-Rasmus
On Fri, 28 May 2004, Jim Jagielski wrote:
> I've bac
On Tue, 9 Mar 2004, Jim Jagielski wrote:
> There are a few open patches floating about,
but in general I think
> we're close to a point where we should seriously consider 1.
On Mon, 17 Nov 2003, Jim Jagielski wrote:
> On Nov 17, 2003, at 2:22 PM, Bill Stoddard wrote:
> >
> > In this economic environment (and perhaps this will turn out to be
> > generally true from now on), companies are not making investments in
> > IT unless they can get a proven and almost immediat
On Mon, 17 Nov 2003, Jim Jagielski wrote:
> Glenn wrote:
> >
> > On Mon, Nov 17, 2003 at 01:31:55PM -0500, Bill Stoddard wrote:
> > > Apache 1.4, an APR'ized version of Apache 1.3 (to pick up IPV6 and 64 bit
> > > support) with all the Windows specific code stripped out and source
> > > compata
On Mon, 17 Nov 2003, Bill Stoddard wrote:
> Apache 1.4, an APR'ized version of Apache 1.3 (to pick up IPV6 and 64 bit support)
> with all the Windows
> specific code stripped out and source compatability (to the extent possible) with
> Apache 1.3 modules would
> probably see rapid uptake. I can
On Mon, 17 Nov 2003, Ian Holsman wrote:
> I belive 2.0 beats 1.3 on these metrics, but like everyone here, Ihave
> no more energy proving/disproving which is faster.. 2.0 works for me,
> and thats all I really care about, not who else is using it.
Do you really believe this to be true for Apache
On Sun, 16 Nov 2003, Marc Slemko wrote:
> 3. Threading issues. This is a red herring; threading issues can be a
> reason why moving to 2.0 wouldn't give someone enough of a reason to make
> it worthwhile, but they do not block anyone moving to 2.0. if they
> don't want to use threads, they don't
On Sun, 16 Nov 2003, Jim Jagielski wrote:
> So a useful topic is: What is *missing* in 1.3 that needs to be
> addressed.
> What are the features/additions that the disenfranchised 1.3 developers
> want to add to 1.3...
How about support for chunked compressed responses right in
src/main/buff.c w
On Sun, 16 Nov 2003, Jeff Trawick wrote:
> The point was not to blame anybody. Instead, I don't believe there are so many
> people as you imply. Many of the people who are no longer developing have
> moved on to other interests/work/etc. and have dropped out of httpd dev because
> of that.
>
On Sun, 16 Nov 2003, Graham Leggett wrote:
> I think the key thing is "bugfixes" compared to "features" and
> "architecture changes".
>
> I am +1 on seeing bugfixes go into v1.3 - people are using it, and if it
> can work better, so be it. But to actively encourage people to add
> features or a
On Sun, 16 Nov 2003, Jeff Trawick wrote:
> Too bad all these supposedly-disenfranchised people aren't around to review 1.3
> fixes. 1.3 would be healthier if they were.
And it is the reason for why they are not around that is in question here.
Why wouldn't there be plenty of hackers around for
On Sun, 16 Nov 2003, Jeff Trawick wrote:
> > *** We need to get back many of the disenfranchised Apache 1.3 developers
>
> Who are these people?
/me raises a hand
People have suggested that we have fewer developers today because Apache 2
is too complex. That the crappy economy has reduced the
That's what the perchild mpm is for. You can't do this with prefork.
-Rasmus
On Sat, 21 Jun 2003, Pablo Yaggi wrote:
> Well, sorry if I'm bodering you with this kind of questions,
> Using prefork I want to change the user ID that process the request,
> that user id will be based on the re
In doing a bit of performance tweaking on 1.3, I noticed that
ap_send_header_field() does an ap_rvputs() with each little piece of a
header which results in separate ap_bwrite() calls for "Primitive", ":",
"Value", "crlf" for each header line sent. Rather than having these 1 and
2 character ap_bwr
> On to a). The PHP developers have screamed quite loudly about the
> failings of Apache2, when, in fact, the largest reason why mod_php will
> not work with Apache2 is because it is not a priority for PHP developers.
Nobody is screaming.
> Personally, my servers run PHP as CGI. Works well. Th
Do you really think we don't know this?
The point is that at this point we would basically have to mutex every
call to every 3rd-party library function since we simply don't know which
ones are threadsafe and which ones aren't. And if we lock everything,
isn't it simpler to just go prefork and
> 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
> 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, 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 app
> 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 linke
> 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
> no
In cvs? But no, it has not. Everyone seems to be ignoring 1.3 these
days.
-Rasmus
On Wed, 27 Nov 2002, Andrei Zmievski wrote:
> Where can I check if it's been committed or not?
>
> On Fri, 22 Nov 2002, Rasmus Lerdorf wrote:
> > +1 on committing this. I finally got
+1 on committing this. I finally got around to testing it.
-Rasmus
On Thu, 7 Nov 2002, Andrei Zmievski wrote:
> Hello,
>
> I am submitting a patch to mod_usertrack for your consideration.
> This patch was developed here at Fast Search & Transfer for
> alltheweb.com and provides the following ch
You mean when you send a request header that looks something like this?
~> telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET / HTTP/1.1
Host: localhost
Connection: foo
HTTP/1.1 200 OK
Date: Wed, 20 Nov 2002 22:52:24 GMT
Server: Apache/1.3.28-dev (Unix)
> On Tue, Oct 01, 2002 at 04:27:15PM -0400, Ryan Bloom wrote:
> > On Tue, 1 Oct 2002, William A. Rowe, Jr. wrote:
> >
> > > At 01:12 PM 10/1/2002, Greg Stein wrote:
> > > >For PHP, we said "make it a filter [so the source can come from anywhere]".
> > > >I think we really should have said "for GET
See his domain name. Novell.com
On Sat, 28 Sep 2002, Jim Jagielski wrote:
> Ramesh Shankar wrote:
> >
>
> Threads? Is this under Win32?
> --
> ===
>Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
> > While we believe that the El-Kabong codebase is a valuable contribution
> > that we would like to pick up, we also recognize the possibility that
> > you may have a decreased incentive to work on it further if you are
> > initially denied commit access to the repository when it moves to the
>
Contributions are more than welcome.
On Tue, 10 Sep 2002, Cyrille Artho wrote:
> Hi,
> as someone who works on multi-threaded problems, but not Apache, I ran
> into your page at
> http://httpd.apache.org/docs-2.0/developer/thread_safety.html
>
> I strongly suggest to revise it, because it lacks
> > Which closed doors are those? There has been discussion on the dev list
> > and on the board list. Both of which are public lists that you can
> > subscribe to.
>
> All I know of is the PMC list (which is private), but discussion on
> board@ (which is also private) is news to me.
Well, I ha
> The ASF is apparently not about working together, since I (and
> everyone else who is not on the PMC list) have been entirely left
> out of all this conversation which is going on behind closed doors.
Which closed doors are those? There has been discussion on the dev list
and on the board list
> On Tue, 3 Sep 2002, Rasmus Lerdorf wrote:
>
> > > On Tue, 3 Sep 2002, Chris Taylor wrote:
> > >
> > > > -BEGIN PGP SIGNED MESSAGE-
> > > > Hash: SHA1
> > > >
> > > > > [ ] Check in aaa rewrite to 2.0.
>
> On Tue, 3 Sep 2002, Chris Taylor wrote:
>
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > > [ ] Check in aaa rewrite to 2.0.
> > > [X] Check in aaa rewrite to 2.1.
> >
> > My view is that it's important to keep 2.0 stable to attract new
> > users, and breaking things all the time w
I see them
On Tue, 27 Aug 2002 [EMAIL PROTECTED] wrote:
>
> I realized earlier today that I haven't been seeing commit messages.
>
> Is anybody getting these messages?
>
> Ryan
>
> --
>
> ___
> Ryan Bloom
> FWIW, I'm +1 on what Rasmus says - at least for widely used libraries.
> Obviously anything internal to PHP is PHP's problem. But anything
> everyone uses is our problem.
>
> However, I would advocate fixing the libraries rather than wrapping them
> where possible.
Yup, definitely. They aren't
odules you choose to use with the web
> server are thread-safe. Please contact your third-party modules' vendors for
> more information on their thread-safety."
>
> -g
>
> On Thu, Aug 15, 2002 at 10:09:27AM -0700, Justin Erenkrantz wrote:
> > On Thu, Aug 15, 2002 a
On Thu, 15 Aug 2002, Justin Erenkrantz wrote:
> [ Moving to dev@httpd where this belongs ]
>
> On Thu, Aug 15, 2002 at 07:10:02AM -0700, Rasmus Lerdorf wrote:
> > Correct. From the feedback I am getting, users do not adequately
> > understand the implications of choosin
> >If we end up having to mutex, sure, if every request for that domain needs
> >to access the mutxed library, then yes, you would only be able to serve up
> >one request at a time from that domain.
> >
> >
>
> That's not accurate in general. The amount of serialization will depend on
> how much
> Hi Rasmus Lerdorf,
> you wrote.
>
> RL> libraries as well. We are going to have to fix a bunch of them and mutex
> RL> some others before Apache2 with a threaded MPM will be of any use with PHP
> RL> or mod_perl.
>
> Am I correct assuming that when they are
> > Apache 2 is being pitched as a production-quality web server without any
> > mention of the fact that over half of the current Apache sites probably
> > should not upgrade at this point.
>
> Sorry to disagree, Rasmus, but if you're talking about PERCHILD, that's a
> threaded MPM that will not
> > I am sure it does, but you also need to recognize that around 40% of all
> > Apache installations have PHP on them. And 30% or so have mod_perl. Many
> > actually have both, so there is some overlap, but I would say that over
> > half of all Apache installs have one or both of PHP or mod_per
> I agree with Pier, the threaded MPM has been a real lifesaver. Supporting
> 10,000+ concurrent clients with Apache 1.3 (including some complex modules)
> on AIX and Solaris is practically impossible. Quite doable with Apache 2.0
> and the worker MPM.
I am sure it does, but you also need to rec
> Hello,
> I've more or less accepted that perchild on FreeBSD 4.X isn't going to
> happen (as sad as it is, I always considered it to be THE feature [1] in
> 2.0 that would warrant an upgrade for us) but what I'd like to know is
> if there is any chance to see perchild on FreeBSD 5 which gets who
> On Sat, Jul 06, 2002 at 03:11:20PM -0400, [EMAIL PROTECTED] wrote:
> > We just added a new function for all input filters to allow this to be
> > done (Justin referenced it in his reply). However, that function doesn't
> > solve the problem, because there should be an ap_filter_is_dynamic(r) th
> > What is a dynamic page if not a PHP page?
>
> Like I said, Apache doesn't know if a file on disk is meant for PHP or
> not. The best way to fix this would be for mod_php to set the value if
> the filter is added for the request.
>
> I agree, it would be cool if Apache could set this correctly
> > > Make sure you have AcceptPathInfo On
> >
> > Argh! Why the heck is that off by default?
>
> It's on by default for dynamic pages, but there is no way that Apache
> can tell that a page is going to be served by PHP, so it is off for what
> Apache thinks are static pages.
What is a dynamic p
On Sat, 6 Jul 2002, Dale Ghent wrote:
> On Sat, 6 Jul 2002, Rasmus Lerdorf wrote:
>
> | 2.0.40-dev built on June 23rd
>
> Make sure you have AcceptPathInfo On
Argh! Why the heck is that off by default?
-Rasmus
2.0.40-dev built on June 23rd
On Sat, 6 Jul 2002, Dale Ghent wrote:
> On Sat, 6 Jul 2002, Rasmus Lerdorf wrote:
>
> | The requested URL /index.php/foo was not found on this server.
> |
> | In Apache1 /index.php would still get passed to PHP and /foo would end up
> | in the PA
With this config:
LoadModule php4_modulemodules/libphp4.so
AddType application/x-httpd-php .php
http://localhost/index.php
works fine and parser PHP pages without problems. (using prefork - but it
shouldn't matter)
However: http://localhost/index.php/foo
Gives a 404 and says:
The re
http://www.apache.org/dist/httpd/patches/ has patches for every released
version of Apache 1.2.x and 1.3.x
On Wed, 3 Jul 2002, Andrew Ho wrote:
> Hello,
>
> Is there a patch for earlier versions of Apache that fix the chunked
> Transfer-Encoding security hole, but nothing else? I know OpenBSD, f
With Apache 1.3 all you had to do to get a keep-alive was set your
content-length correctly:
HTTP/1.1 200 OK
Date: Mon, 24 Jun 2002 17:05:04 GMT
Server: Apache/1.3.22 (Unix) PHP/4.3.0-dev
X-Powered-By: PHP/4.3.0-dev
Content-length: 1024
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Conte
> * Saying "turn on buffering" is, IMHO, a reasonable solution if you
> can make buffering the default in PHP under httpd-2.0. Otherwise,
> you'll surprise a lot of users who have been running with the default
> non-buffered output using 1.3 and find that all their applications
> are far
> As it happens, DONE is defined to be -2. :-)
Ok, I will use that, but 'DONE' doesn't really give the impression of
being a fatal error return value.
-Rasmus
On Mon, 24 Jun 2002, Cliff Woolley wrote:
> On Mon, 24 Jun 2002, Rasmus Lerdorf wrote:
>
> > Hrm.. Nope. doing 'return DECLINED' from the post_config phase does not
> > stop the server from starting. I have this:
>
> I thought you were supposed to return HTTP_
On Mon, 24 Jun 2002, Rasmus Lerdorf wrote:
> > > What is the correct way to fail in a filter post_config? Do I return
> > -1
> > > from it if my filter finds a fatal error? I can't use ap_log_rerror()
> > at
> > > this point, right? How would I
> > What is the correct way to fail in a filter post_config? Do I return
> -1
> > from it if my filter finds a fatal error? I can't use ap_log_rerror()
> at
> > this point, right? How would I log the reason for the failure?
>
> I'm confused by the question, but I'll try to answer. If you mean
> Runtime is harder, but you can just use ap_mpm_query to get the MPMs
> characteristics. This won't give you the MPM name, but it will let you
> know if the MPM is threaded or not.
What is the correct way to fail in a filter post_config? Do I return -1
from it if my filter finds a fatal error?
> > > It would be nice
> > > if there was an apxs flag that would return the MPM type.
> >
> > +1
>
> There is. -q will query for any value in config_vars.mk, and MPM_NAME
> is in that file. So `apxs -q MPM_NAME` will return the configured MPM
> type.
Ah right. Is there a way to check at runti
Someone asked me for numbers when I mentioned the other day that Apache
2-prefork was really not a viable drop-in replacement for Apache 1.3 when
it comes to running a PHP-enabled server.
Apache 1.3 is still significantly faster than Apache2-prefork for both
static and dynamic content. Now, part
Could someone karma me for apache-2.0 please?
-Rasmus
On Tue, 18 Jun 2002, Rick Kukiela wrote:
> In the last episode (Jun 17), Rick Kukiela said:
> > I asked on the apache-dev list about when perchild processing will work on
> > freebsd and this was the response i got:
> >
> > "It will never work with FreeBSD 4.6. Perchild requires a good threading
mod_info will tell you some of this. ie. Look for ScriptAlias lines under
mod_alias.c and AddHandler cgi-script lines under mod_mime.c.
But you are fighting a bit of a lost cause here. If you allow users to
upload arbitrary cgi scripts there really isn't much you can do at the
Apache level. It
> Right now PATH_INFO is not automatically passed to PHP scripts in the
> Apache 2.0 module for PHP. I have a patch on my plate that enables it
> by default, but for now you can add "AcceptPathInfo On" to the directory
> or location sections where you want it to work.
That should go in. Why woul
1 - 100 of 113 matches
Mail list logo
