Re: cvs commit: httpd-2.0/modules/ssl ssl_engine_io.c
On 5 Nov 2002 [EMAIL PROTECTED] wrote:
>
> -if (APR_STATUS_IS_EOF(status) && (status != APR_SUCCESS)) {
> +if (!APR_STATUS_IS_EOF(status) && (status != APR_SUCCESS)) {
>break;
>}
Ohhh now THAT makes sense. :) Okay. :)
--Cliff
Re: cvs commit: httpd-2.0/modules/ssl ssl_engine_io.c
--On Tuesday, November 5, 2002 3:16 AM + [EMAIL PROTECTED] wrote: wrowe 2002/11/04 19:16:33 Modified:modules/ssl ssl_engine_io.c Log: At least one doc I've seen says EOF+bytes is valid. This was a typo. That'd be in the docs for apr_recv() which socket_bucket_read uses. -- justin
Re: dynamically change max client value
Interesting comments, thanks. You obviously speak from experience. The idea I was having is that no matter how overloaded a machine becomes, it should never run so far out of resources that it dies, but there should be some kind of limit in place... I thought this was what MaxClients was for, however it varies too greatly what the optimum value is depending on what's getting hit so I don't know what to do about it... Your idea of a reverse proxy in front (or module) turning away or redirecting some requests in a very light fashion deserves merit... I know that Excite.com used to have a very light static home page they'd slap up during peak loads for this very reason, I'll investigate something like that for the solution to my problem instead of what I originally suggested, thanks. Dave At 12:01 PM 11/4/2002 -0800, Scott Hess wrote: >Based on my experience, this wouldn't be a high-quality solution, it would >be a hack. I've seen very few cases where load spiked enough to be an >issue, but was transient enough that a solution like this would work - and >in those cases, plain old Unix multitasking normally suffices. > >What happens if you implement the solution anyhow is that you get a bunch >of users stuck in the ListenBacklog. So they'll wait a couple minutes >before their request even starts. If you have a deep backlog, requests >just pile up so that the machine never gets its head above water. In the >worst case, clients will timeout while their request is in the backlog, >but since you don't find that out until you send a response which writes >out to the network, you can very easily do work that can never be >delivered. Beyond all that, the user experience simply _sucks_. > >[Yes, I've done what you suggest, just not using the implementation you >suggest. It's integrated into an existing custom module, you could also >probably do it with a reverse proxy. In the end, it was not a productive >solution.] > >What I think you really want is a module that will intercept all requests, >and send back "The server is really busy, try again in five minutes" if >the server is too busy by some measure. You generally want this to be a >super-low-cost option, so that you can spin through requests very quickly. >Optimally, no externally-blockable pieces (no database connections, no >locking filesystem access, etc). One relatively simple option might be to >use a Squid, and an URL redirector which implements the magic check. If >the machine is not busy, send through to the real server, if the machine >is busy, redirect to an URL which will deliver your message. > >[Again, yes, I've done this in Apache1.3, but in code targetted to our >custom modules. You could certainly do it more generically, I just >haven't had the need. You might check mod_backhand.] > >Later, >scott > > >On Mon, 4 Nov 2002, David Burry wrote: >> I realize that allowing _everything_ to be dynamically configured via >> SNMP (or signal or something) would probably be too substantial of an >> API change to be considered for the current code base, but it would be >> nice to consider it for some future major revision of Apache >> >> And it would be more than just "nice" if at least the max client value >> thing could be somehow worked into the current versions of Apache... >> There is a current very real and very large problem that could be solved >> by this, not just a "nice to have" feature. This is what I meant to >> emphasize in my original email... >> >> Dave >> >> - Original Message - >> From: "Dirk-Willem van Gulik" <[EMAIL PROTECTED]> >> To: <[EMAIL PROTECTED]> >> Sent: Monday, November 04, 2002 9:35 AM >> Subject: Re: dynamically change max client value >> >> >> > >> > In my ideal world every config directive would be able to advertize or >> > register an optional 'has changed' hook. Which, if present, would be >> > called in context whenever a value is somehow updated (through snmp, a >> > configd, signal, wathever). If there is no such hook; the old -update- on >> > graceful restart is the default (though it sure would be nice to have some >> > values also advertize that they need a full shutdown and restart). >> > >> > Of course one could also argue for not just a put but also for a 'get' >> > interface in context :-) >> > >> > Dw >> > >> > On Mon, 4 Nov 2002, David Burry wrote: >> > >> > > Recently there has been a little discussion about an API in apache for >> > > controlling starts, stops, restarts, etc... >> > > >> > > I have an idea that may help me solve a problem I've been having. The >> > > problem is in limiting the number of processes that will run on a >> machine to >> > > somewhere below where the machine will keel over and die, while still >> being >> > > close to the maximum the machine will handle. The issue is depending on >> > > what the majority of those processes are doing it changes the maximum >> number >> > > a given machine can handle by a few orders of magnitude, so a
Re: cvs commit: httpd-2.0/modules/loggers mod_logio.c
OOPS, sorry. I was following the mod_apachecon.c, which seems a bit out
of date :-(
Bojan
On Sat, 2002-11-02 at 05:07, [EMAIL PROTECTED] wrote:
> wrowe 2002/11/01 10:07:53
>
> Modified:os/win32 BaseAddr.ref
>modules/loggers mod_logio.c
> Log:
> Well that was a little borked, if you were having stack problems using
> logio the missing pre_connection hook declartion could have something
> to do with it.
>
> Revision ChangesPath
> 1.22 +1 -0 httpd-2.0/os/win32/BaseAddr.ref
>
> Index: BaseAddr.ref
> ===
> RCS file: /home/cvs/httpd-2.0/os/win32/BaseAddr.ref,v
> retrieving revision 1.21
> retrieving revision 1.22
> diff -u -r1.21 -r1.22
> --- BaseAddr.ref14 Sep 2002 16:34:16 - 1.21
> +++ BaseAddr.ref1 Nov 2002 18:07:52 - 1.22
> @@ -60,3 +60,4 @@
>mod_authz_groupfile 0x6FB10x0001
>mod_authz_host 0x6FB00x0001
>mod_authz_user 0x6FAF0x0001
> +mod_logio0x6FAE0x0001
>
>
>
> 1.3 +2 -1 httpd-2.0/modules/loggers/mod_logio.c
>
> Index: mod_logio.c
> ===
> RCS file: /home/cvs/httpd-2.0/modules/loggers/mod_logio.c,v
> retrieving revision 1.2
> retrieving revision 1.3
> diff -u -r1.2 -r1.3
> --- mod_logio.c 25 Oct 2002 06:52:02 - 1.2
> +++ mod_logio.c 1 Nov 2002 18:07:52 - 1.3
> @@ -81,6 +81,7 @@
>#include "httpd.h"
>#include "http_core.h"
>#include "http_config.h"
> +#include "http_connection.h"
>#include "http_protocol.h"
>
>module AP_MODULE_DECLARE_DATA logio_module;
> @@ -182,7 +183,7 @@
> * The hooks...
> */
>
> -static int logio_pre_conn(conn_rec *c) {
> +static int logio_pre_conn(conn_rec *c, void *csd) {
>logio_config_t *cf = apr_pcalloc(c->pool, sizeof(*cf));
>
>ap_set_module_config(c->conn_config, &logio_module, cf);
>
>
>
>
Re: dynamically change max client value
Based on my experience, this wouldn't be a high-quality solution, it would be a hack. I've seen very few cases where load spiked enough to be an issue, but was transient enough that a solution like this would work - and in those cases, plain old Unix multitasking normally suffices. What happens if you implement the solution anyhow is that you get a bunch of users stuck in the ListenBacklog. So they'll wait a couple minutes before their request even starts. If you have a deep backlog, requests just pile up so that the machine never gets its head above water. In the worst case, clients will timeout while their request is in the backlog, but since you don't find that out until you send a response which writes out to the network, you can very easily do work that can never be delivered. Beyond all that, the user experience simply _sucks_. [Yes, I've done what you suggest, just not using the implementation you suggest. It's integrated into an existing custom module, you could also probably do it with a reverse proxy. In the end, it was not a productive solution.] What I think you really want is a module that will intercept all requests, and send back "The server is really busy, try again in five minutes" if the server is too busy by some measure. You generally want this to be a super-low-cost option, so that you can spin through requests very quickly. Optimally, no externally-blockable pieces (no database connections, no locking filesystem access, etc). One relatively simple option might be to use a Squid, and an URL redirector which implements the magic check. If the machine is not busy, send through to the real server, if the machine is busy, redirect to an URL which will deliver your message. [Again, yes, I've done this in Apache1.3, but in code targetted to our custom modules. You could certainly do it more generically, I just haven't had the need. You might check mod_backhand.] Later, scott On Mon, 4 Nov 2002, David Burry wrote: > I realize that allowing _everything_ to be dynamically configured via > SNMP (or signal or something) would probably be too substantial of an > API change to be considered for the current code base, but it would be > nice to consider it for some future major revision of Apache > > And it would be more than just "nice" if at least the max client value > thing could be somehow worked into the current versions of Apache... > There is a current very real and very large problem that could be solved > by this, not just a "nice to have" feature. This is what I meant to > emphasize in my original email... > > Dave > > - Original Message - > From: "Dirk-Willem van Gulik" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Monday, November 04, 2002 9:35 AM > Subject: Re: dynamically change max client value > > > > > > In my ideal world every config directive would be able to advertize or > > register an optional 'has changed' hook. Which, if present, would be > > called in context whenever a value is somehow updated (through snmp, a > > configd, signal, wathever). If there is no such hook; the old -update- on > > graceful restart is the default (though it sure would be nice to have some > > values also advertize that they need a full shutdown and restart). > > > > Of course one could also argue for not just a put but also for a 'get' > > interface in context :-) > > > > Dw > > > > On Mon, 4 Nov 2002, David Burry wrote: > > > > > Recently there has been a little discussion about an API in apache for > > > controlling starts, stops, restarts, etc... > > > > > > I have an idea that may help me solve a problem I've been having. The > > > problem is in limiting the number of processes that will run on a > machine to > > > somewhere below where the machine will keel over and die, while still > being > > > close to the maximum the machine will handle. The issue is depending on > > > what the majority of those processes are doing it changes the maximum > number > > > a given machine can handle by a few orders of magnitude, so a > multi-purpose > > > machine that serves, say, static content and cgi scripts (or other > things > > > that vary greatly in machine resource usage) cannot be properly tuned > for > > > maximum performance while guaranteeing the machine won't die under heavy > > > load. > > > > > > The solution I've thought of is... what if Apache had an API that could > be > > > used to say "no more processes, whatever you have NOW is the max!" or > > > otherwise to dynamically raise or lower the max number (perhaps "oh > there's > > > too many, reduce a bit") You see, an external monitoring system > could > > > monitor cpu and memory and whatnot and dynamically adjust apache > depending > > > on what it's doing. This kind of system could really increase the > > > stability of any large Apache server farm, and help keep large traffic > > > spikes from killing apache so bad that nobody gets served anything at > all. > > > > > > In fact
Re: dynamically change max client value
I realize that allowing _everything_ to be dynamically configured via SNMP (or signal or something) would probably be too substantial of an API change to be considered for the current code base, but it would be nice to consider it for some future major revision of Apache And it would be more than just "nice" if at least the max client value thing could be somehow worked into the current versions of Apache... There is a current very real and very large problem that could be solved by this, not just a "nice to have" feature. This is what I meant to emphasize in my original email... Dave - Original Message - From: "Dirk-Willem van Gulik" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, November 04, 2002 9:35 AM Subject: Re: dynamically change max client value > > In my ideal world every config directive would be able to advertize or > register an optional 'has changed' hook. Which, if present, would be > called in context whenever a value is somehow updated (through snmp, a > configd, signal, wathever). If there is no such hook; the old -update- on > graceful restart is the default (though it sure would be nice to have some > values also advertize that they need a full shutdown and restart). > > Of course one could also argue for not just a put but also for a 'get' > interface in context :-) > > Dw > > On Mon, 4 Nov 2002, David Burry wrote: > > > Recently there has been a little discussion about an API in apache for > > controlling starts, stops, restarts, etc... > > > > I have an idea that may help me solve a problem I've been having. The > > problem is in limiting the number of processes that will run on a machine to > > somewhere below where the machine will keel over and die, while still being > > close to the maximum the machine will handle. The issue is depending on > > what the majority of those processes are doing it changes the maximum number > > a given machine can handle by a few orders of magnitude, so a multi-purpose > > machine that serves, say, static content and cgi scripts (or other things > > that vary greatly in machine resource usage) cannot be properly tuned for > > maximum performance while guaranteeing the machine won't die under heavy > > load. > > > > The solution I've thought of is... what if Apache had an API that could be > > used to say "no more processes, whatever you have NOW is the max!" or > > otherwise to dynamically raise or lower the max number (perhaps "oh there's > > too many, reduce a bit") You see, an external monitoring system could > > monitor cpu and memory and whatnot and dynamically adjust apache depending > > on what it's doing. This kind of system could really increase the > > stability of any large Apache server farm, and help keep large traffic > > spikes from killing apache so bad that nobody gets served anything at all. > > > > In fact this idea could be extended someday to dynamically change all sorts > > of apache configuration things, but all I really need that I know of right > > now is the max client value... > > > > What do you all think of this idea? Does this already exist perhaps? > > > > Dave > > > > >
Re: New Module: mod_auth_mysql_digest
måndagen den 4 november 2002 19.26 skrev Rob Emanuele: > I'm making another pass at this code in a week or so. Is there any > stable tree that has the new provider code in it or shall I get the > bleeding-edge code out of CVS? why no mod_log_mysql ? -- Regards // Oden Eriksson, Deserve-IT Networks Check the "Modules For Apache2" status page at: http://www.deserve-it.com/modules_for_apache2.html
RE: New Module: mod_auth_mysql_digest
I'm making another pass at this code in a week or so. Is there any stable tree that has the new provider code in it or shall I get the bleeding-edge code out of CVS? Thanks, Rob -Original Message- From: [EMAIL PROTECTED] [mailto:trawick@;rdu74-177-063.nc.rr.com] On Behalf Of Jeff Trawick Sent: Monday, November 04, 2002 4:22 AM To: [EMAIL PROTECTED] Subject: Re: New Module: mod_auth_mysql_digest Justin Erenkrantz <[EMAIL PROTECTED]> writes: > --On Friday, November 01, 2002 16:02:45 -0800 Rob Emanuele > <[EMAIL PROTECTED]> wrote: > > > So I took the mod_auth_digest code and munged it to use mysql for > > authentication. Swell. It works great and we're heavily using it. > If you'd be willing to write this as an auth provider, I'm sure we > might be interested in integrating it in our tree. -- justin absolutely -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: dynamically change max client value
In my ideal world every config directive would be able to advertize or register an optional 'has changed' hook. Which, if present, would be called in context whenever a value is somehow updated (through snmp, a configd, signal, wathever). If there is no such hook; the old -update- on graceful restart is the default (though it sure would be nice to have some values also advertize that they need a full shutdown and restart). Of course one could also argue for not just a put but also for a 'get' interface in context :-) Dw On Mon, 4 Nov 2002, David Burry wrote: > Recently there has been a little discussion about an API in apache for > controlling starts, stops, restarts, etc... > > I have an idea that may help me solve a problem I've been having. The > problem is in limiting the number of processes that will run on a machine to > somewhere below where the machine will keel over and die, while still being > close to the maximum the machine will handle. The issue is depending on > what the majority of those processes are doing it changes the maximum number > a given machine can handle by a few orders of magnitude, so a multi-purpose > machine that serves, say, static content and cgi scripts (or other things > that vary greatly in machine resource usage) cannot be properly tuned for > maximum performance while guaranteeing the machine won't die under heavy > load. > > The solution I've thought of is... what if Apache had an API that could be > used to say "no more processes, whatever you have NOW is the max!" or > otherwise to dynamically raise or lower the max number (perhaps "oh there's > too many, reduce a bit") You see, an external monitoring system could > monitor cpu and memory and whatnot and dynamically adjust apache depending > on what it's doing. This kind of system could really increase the > stability of any large Apache server farm, and help keep large traffic > spikes from killing apache so bad that nobody gets served anything at all. > > In fact this idea could be extended someday to dynamically change all sorts > of apache configuration things, but all I really need that I know of right > now is the max client value... > > What do you all think of this idea? Does this already exist perhaps? > > Dave > >
dynamically change max client value
Recently there has been a little discussion about an API in apache for controlling starts, stops, restarts, etc... I have an idea that may help me solve a problem I've been having. The problem is in limiting the number of processes that will run on a machine to somewhere below where the machine will keel over and die, while still being close to the maximum the machine will handle. The issue is depending on what the majority of those processes are doing it changes the maximum number a given machine can handle by a few orders of magnitude, so a multi-purpose machine that serves, say, static content and cgi scripts (or other things that vary greatly in machine resource usage) cannot be properly tuned for maximum performance while guaranteeing the machine won't die under heavy load. The solution I've thought of is... what if Apache had an API that could be used to say "no more processes, whatever you have NOW is the max!" or otherwise to dynamically raise or lower the max number (perhaps "oh there's too many, reduce a bit") You see, an external monitoring system could monitor cpu and memory and whatnot and dynamically adjust apache depending on what it's doing. This kind of system could really increase the stability of any large Apache server farm, and help keep large traffic spikes from killing apache so bad that nobody gets served anything at all. In fact this idea could be extended someday to dynamically change all sorts of apache configuration things, but all I really need that I know of right now is the max client value... What do you all think of this idea? Does this already exist perhaps? Dave
Re: [PATCH] checking for failures encountered by core_output_filter
Justin Erenkrantz <[EMAIL PROTECTED]> writes: > >> I don't buy that logic at all. Why should we be returning > >> APR_SUCCESS here? We want to signal an error, so that the filters > >> stop what they are doing and exit. > > > > Talk to Ryan :) > > Well, he ain't here no more. Just us folks. Do you (or anyone else) > see a reason why we shouldn't change this? interpret "Talk to Ryan" as "I can't justify the current behavior" :) We should make the change to return an APR error code here. > > I'm kinda stuck thinking that the philosophy should be that we log > > whatever was written to the client in the status line, but there are > > some implementation details with that one. > > How do we differentiate between a 200 that all the data was sent for > and a 200 where the client aborted? If someone looked at the access > logs, they would see that the transmitted length wasn't correct in the > aborted case. Perhaps that was Ryan's initial motivation - did he > want the length to be what we wanted to send not what we actually > sent? (mod_logio is bringing up some of these concerns as well.) > > I guess I'd like to see some notation in access log that indicates, > "Hey, we know we didn't send everything, but that's because they left > in the middle." Yes, it also might be noted in the error log, but I > gotta believe it's goodness to have tools looking at just the access > logs know that the client aborted. FWIW, this is what happens with 1.3 when the client drops the connection before reading the entire response. In this case, the client read several bytes of a 1MB response (though the client TCP accepted a lot more). [Mon Nov 4 10:31:22 2002] [info] [client 9.27.32.119] (32)Broken pipe: client stopped connection before send mmap completed 9.27.32.119 - - [04/Nov/2002:10:31:22 -0500] "GET /bigfile.html" 200 65536 Even though Apache could have noticed that it sent only 64K out of 1MB, it still logged 200. The 64K isn't even an indication of how much the client really read. It is simply how much TCP was willing to buffer. Also, I suspect that we can hit the first indication of a dropped connection after the previous response has been noted in the log. I'm not sure what promises we can make about what is in the access log. > > One issue with that is that the filter that encounters the error > > really should do the logging so that the most specific information > > is available. If some other code also logs less-specific info, > > then it is all for naught. > > Makes sense. So, core_output_filter should be calling > ap_log_rerror. Hmm. Does it have access to the request_rec? Didn't > we change that? Or, was I vetoed on that? -- justin I don't recall that conversation. Regardless, I wonder how core_output_filter could know the r associated with a particular bucket? -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: cvs commit: httpd-2.0/modules/loggers mod_logio.c
At 03:50 PM 11/1/2002, Greg Stein wrote: On Fri, Nov 01, 2002 at 06:07:53PM -, [EMAIL PROTECTED] wrote: >... > +++ BaseAddr.ref1 Nov 2002 18:07:52 - 1.22 > @@ -60,3 +60,4 @@ >mod_authz_groupfile 0x6FB10x0001 >mod_authz_host 0x6FB00x0001 >mod_authz_user 0x6FAF0x0001 > +mod_logio0x6FAE0x0001 For efficiency purposes, those numbers should be as close together as possible. FYI, these are as close together as possible. You can't specify the addresses with any finer granularity than 0x1. I don't recall how to find the size of the module; If you're on WinNT, you can use Quick View. I'm not sure in Win2K, other than just checking the size of the executable in Windows Explorer. Also, the reason for the 0x0001 at the end of the line is so the linker knows how much space you've allocated for the module. If it module is larger than that size, a warning will be issued at link time. -- Greg Marr [EMAIL PROTECTED]
Re: Patch for listen.c
Randall Stewart <[EMAIL PROTECTED]> writes: > hmmm so what I think you are saying is that if only one > port is listened to all children can do a poll() on the sd otherwise > you must have only one thread to the poll() I guess so it could > dispatch out the work... Bill answered this. > Do you suggest then a > > Listen, tcp:80 > Listen, sctp:80 > > type syntax... or what would be the format wanted in the config... I would suggest following/participating in this thread: multiple protocols - Patch for listen.c I haven't had a chance to look over the conversation yet. -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
RE: mod_blank dev
If you do: SetOutputFilter BLANK;DEFLATE should work with no problems. Best regards, Juan C. Rivera Citrix Systems, Inc. -Original Message- From: Justin Erenkrantz [mailto:jerenkrantz@;apache.org] Sent: Sunday, November 03, 2002 2:04 PM To: [EMAIL PROTECTED] Subject: Re: mod_blank dev --On Sunday, November 3, 2002 11:08 AM +0100 fabio rohrich <[EMAIL PROTECTED]> wrote: > Have I to fill the blank_cmds if I have a directive? > And I need a directive? Or more than one? And which? I would strongly suggest reading how other modules do this. Since your module should be implemented as a filter, I would recommend looking at mod_deflate in modules/filters/mod_deflate.c. You will see examples on how to do multiple directives there (see deflate_filter_cmds). I'll be curious to see how mod_deflate and mod_blank would work together. Good luck! -- justin
RE: Patch for listen.c
> Jeff Trawick wrote: > > Randall Stewart <[EMAIL PROTECTED]> writes: > > > > > >>The idea behind this is that SCTP is automatically enabled if > >>available... i.e. there is no flag to turn it on/off.. if you say > >>listen 80 > >>and have sctp.. you get a listener on both TCP and SCTP port 80. > >> > >>Now the reason I picked this method is: > >> > >>a) A port/socket listening is a small amount of overhead... > > > > > > unfortunately, it can be meaningful overhead, enough so that IMHO it > > isn't reasonable to enable SCTP automatically > > > > when Apache has more than one listening socket, it is forced to poll() > > in addition to accept(), and the use of poll() prior to accept() means > > it has to serialize all threads/processes such that only one is in > > poll() at a time > > hmmm so what I think you are saying is that if only one > port is listened to all children can do a poll() on the sd otherwise > you must have only one thread to the poll() I guess so it could > dispatch out the work... > If you are only listening to one port, you can can skip the poll() and have all threads block on the accept(). poll(), unlike accept(), does not work correctly if you allow multiple threads to call it. Bill
Re: Patch for listen.c
Jeff Trawick wrote: Randall Stewart <[EMAIL PROTECTED]> writes: The idea behind this is that SCTP is automatically enabled if available... i.e. there is no flag to turn it on/off.. if you say listen 80 and have sctp.. you get a listener on both TCP and SCTP port 80. Now the reason I picked this method is: a) A port/socket listening is a small amount of overhead... unfortunately, it can be meaningful overhead, enough so that IMHO it isn't reasonable to enable SCTP automatically when Apache has more than one listening socket, it is forced to poll() in addition to accept(), and the use of poll() prior to accept() means it has to serialize all threads/processes such that only one is in poll() at a time hmmm so what I think you are saying is that if only one port is listened to all children can do a poll() on the sd otherwise you must have only one thread to the poll() I guess so it could dispatch out the work... on most current OSs, this serialization is not necessary when there is only one listening socket Do you suggest then a Listen, tcp:80 Listen, sctp:80 type syntax... or what would be the format wanted in the config... I will find some cycles soon and dig into the config but I would like a pointer to what would be the right choice... -- Randall R. Stewart [EMAIL PROTECTED] 815-342-5222 (cell phone)
Re: New Module: mod_auth_mysql_digest
Justin Erenkrantz <[EMAIL PROTECTED]> writes: > --On Friday, November 01, 2002 16:02:45 -0800 Rob Emanuele > <[EMAIL PROTECTED]> wrote: > > > So I took the mod_auth_digest code and munged it to use mysql for > > authentication. Swell. It works great and we're heavily using it. > If you'd be willing to write this as an auth provider, I'm sure we > might be interested in integrating it in our tree. -- justin absolutely -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: Patch for listen.c
Randall Stewart <[EMAIL PROTECTED]> writes: > The idea behind this is that SCTP is automatically enabled if > available... i.e. there is no flag to turn it on/off.. if you say > listen 80 > and have sctp.. you get a listener on both TCP and SCTP port 80. > > Now the reason I picked this method is: > > a) A port/socket listening is a small amount of overhead... unfortunately, it can be meaningful overhead, enough so that IMHO it isn't reasonable to enable SCTP automatically when Apache has more than one listening socket, it is forced to poll() in addition to accept(), and the use of poll() prior to accept() means it has to serialize all threads/processes such that only one is in poll() at a time on most current OSs, this serialization is not necessary when there is only one listening socket -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: mod_blank dev
fabio rohrich <[EMAIL PROTECTED]> writes: > The reduced space of each page will be saved in a log > file, and the web admin. can decide if the space saved > is a good quantity and to use or not the mod_blank > with that web page. Look at how mod_deflate can optionally log the compression ratio. That is a good model to use for your module. You'd avoid writing some unnecessary code handling your own log. -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: mod_deflate and gzip
fabio rohrich <[EMAIL PROTECTED]> writes: > I don't get the difference between mod_deflate and the > famous gzip! > Can they work together,and what it's the difference > between them? Use one or the other for compression of HTTP. They can't work together because they perform basically the same function. IIRC, mod_gzip has rich set of configuration directives for controlling when it is used or not. mod_deflate is slim on configuration directives and instead relies on generic Apache directives that control filters and environment variables for controlling when it is used or not. (I've never seen/used mod_gzip for 2.0 so I don't know if migration of mod_gzip to a filter led to a change in the configuration mechanisms.) --- Born in Roswell... married an alien...
