About bug 36987: ProxyBlock not blocking all IPs needed

[Viipuri, Timo]

Hi!

Has anyone had a chance to check bug 36987: "mod_proxy: ProxyBlock is not
checked for all IP addresses found in the DNS"?

I think its a quite clear bug and an easy fix.

rgs,
 Timo

Re: [pre-release] 2.0.55 *candidate* available for testing

[Ondrej Sury]

On Wed, 2005-10-12 at 12:10 +0200, Graham Leggett wrote:
> William A. Rowe, Jr. said:
> 
> > So... is it unreasonable in README.RPM to point the user to obtain the
> > current httpd.spec/httpd.in from /dist/httpd/httpd-2.0.55-rpm-src.tar.gz
> > which would be grabbed from svn httpd/package/rpm/, and drop it into the
> > unpacked httpd-2.0.55 source tarball, in order to package?
> 
> Secondly the httpd.spec file contains version specific information (the
> version number, the MMN, etc) that would be both a serious pain to
> maintain separately by a packager and a serious pain to tie up with the
> required source by a person building an RPM.

Sorry, but in DEB world, this is pretty normal to have separate upstream
source and debian/ subdirectory and it's not serious pain at all.
Upstream and packagers work in clearly separated and in my view it's
good.  But my view can be twisted since there are propably a bit
different *standards* how is package provided in DEB and RPM world, ie.
debianers are not used to compile packages themselves a lot, they use
packages provided by their distribution.

O.
P.S.: Please, keep it cool and don't flame.
-- 
Ondrej Sury <[EMAIL PROTECTED]>


signature.asc
Description: This is a digitally signed message part

Re: [pre-release] 2.0.55 *candidate* available for testing

[Graham Leggett]

Ondrej Sury wrote:


Sorry, but in DEB world, this is pretty normal to have separate upstream
source and debian/ subdirectory and it's not serious pain at all.


Exactly, it's normal in the debian world, but it's not normal in the rpm 
world.


Each packaging system has it's own "default" way of handling packaging. 
In the case of RPM, it's "rpmbuild --rebuild yyy.src.rpm", or "rpmbuild 
-tb yyy.tar.gz". Debian does it differently, just like Solaris pkg does 
it differently, but it makes no difference.


I have in the past wasted *hours* of time because the packager of an RPM 
expected the user to "just know" that their package had some weird 
custom process of producing an RPM, and when this was posted as a bug 
the answer was "oh, you should have read the documentation".


I had read the documentation: the rpm man page, which clearly details 
the --rebuild and -tX options.


With packaging, the needs of the users come first, the needs of the 
packager comes second. Sure, it will be nice and neat for packagers to 
have packaging scripts in a single archive, but that's a pain for the 
end user.



Upstream and packagers work in clearly separated and in my view it's
good.  But my view can be twisted since there are propably a bit
different *standards* how is package provided in DEB and RPM world, ie.
debianers are not used to compile packages themselves a lot, they use
packages provided by their distribution.


Virtually all distros offer a somewhat conservative approach to 
packaging - they are typically a few versions behind, and there are good 
reasons for this.


Sometimes however, someone might need a bleeding edge feature not 
offered by a distro, but they might not want to clutter up their system 
with "custom" install trees. The ASF packages serve the needs of this 
group of people.


Regards,
Graham
--


smime.p7s
Description: S/MIME Cryptographic Signature

Re: mpm_winnt incompatible and broken behavior on restart

[Ivan Zhakov]

On 10/13/05, Bill Stoddard <[EMAIL PROTECTED]> wrote:
> Ivan Zhakov wrote:
> > Hi!We have Apache/Subversion server under Windows Server 2003. And I 
> > wascome into problem with restarting server that process long request(more 
> > than 180 seconds). It's usual for bug Subversion repository. Isee messages 
> > like this in error.log:[Thu Oct 13 02:28:01 2005] [notice] Child 3952: 
> > Terminating 1 threadsthat failed to exit.
> > I research problem and that mpm_winnt have hardcoded timeout forstopping 
> > working 
> > threads:http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/server/mpm/winnt/child.c:child_main()/*
> >  Give busy worker threads a chance to service their connections */
> > ap_log_error(APLOG_MARK,APLOG_NOTICE, APR_SUCCESS, ap_server_conf,  
> >"Child %d: Waiting for %d worker threads to exit.",my_pid, 
> > threads_created);end_time = time(NULL) + 180;while 
> > (threads_created) {rv = wait_for_many_objects(threads_created, 
> > child_handles,end_time - time(NULL));if (rv != WAIT_TIMEOUT) {  
> >   rv = rv - WAIT_OBJECT_0;ap_assert((rv >= 0) && (rv < 
> > threads_created));cleanup_thread(child_handles, 
> > &threads_created, rv);continue;}break;}
> > After this timeout Apache terminate worker threads. Why is it? Whympm_winnt 
> > behavior incompatible to perfork behavior which waitsinfinityle for 
> > stopping child processes? It causes really problems onmaintance and also 
> > doesn't permit use MaxRequestsPerChild option.
> > PS: Sorry if it is not right place for such questions.
> > --Ivan Zhakov
> >
> >
> >
>
> Hi Ivan,
> This is definitly the right place for this type of question. I think the few 
> Win32 developers
> here (myself
> included) always had this on their list of 'todo's'. The Windows MPM needs to 
> be
> enhanced to reliably support
> multiple child processes and when that's done, this will be fixed 'for free'.
Hi, Bill!
You meant Worker mpm? To be clear: you cannot simply change timeout to
infinite wait in mpm_wint?
It is really important, because Apache+Subversion is unusable in
production environment under Windows at present time :(

--
Ivan Zhakov

[PATCH] Handle subrequests to non local resources correctly

[Ruediger Pluem]

Hi,

yesterdays I saw discussions on #httpd-dev about the usage of
quick handler vs. normal handler for mod_cache and if mod_cache can handle 
subrequests.

I remembered myself that subrequests to non local resources worked and 
crosschecked this
on the trunk again. I was astonished to find out that they currently do not 
work, but
break somewhere in the middle with the contents of the subrequest body written 
to the
temp file which never gets renamed.
The reason for this is the type of the CACHE_OUT / CACHE_SAVE filter. A while 
ago Paul
changed this from AP_FTYPE_CONTENT_SET-1 to AP_FTYPE_CONTENT_SET+1 to ensure 
that the
cache captures also the results of mod_deflate (if present). This makes a lot 
of sense
for obvious reasons. On the other hand this breaks subrequests as we need to 
have the
cache filters placed *before* the SUBREQ_CORE filter in order to make this work.

So I created a patch which defines four filter handles instead of two:

CACHE_OUT / CACHE_SAVE as AP_FTYPE_CONTENT_SET+1 filters and
CACHE_OUT_SUBREQ / CACHE_SAVE_SUBREQ as AP_FTYPE_CONTENT_SET-1 filters

Depending on the type of request the patch now inserts either the 
AP_FTYPE_CONTENT_SET+1
or the AP_FTYPE_CONTENT_SET-1 filter.

Comments / Thoughts?


Regards

Rüdiger

Index: modules/cache/mod_cache.c
===
--- modules/cache/mod_cache.c   (Revision 315051)
+++ modules/cache/mod_cache.c   (Arbeitskopie)
@@ -28,7 +28,9 @@
  * a name-to-function mapping on each request
  */
 static ap_filter_rec_t *cache_save_filter_handle;
+static ap_filter_rec_t *cache_save_subreq_filter_handle;
 static ap_filter_rec_t *cache_out_filter_handle;
+static ap_filter_rec_t *cache_out_subreq_filter_handle;
 static ap_filter_rec_t *cache_remove_url_filter_handle;
 
 /*
@@ -109,12 +111,27 @@
 if (rv != OK) {
 if (rv == DECLINED) {
 if (!lookup) {
-ap_log_error(APLOG_MARK, APLOG_DEBUG, APR_SUCCESS, r->server,
-  "Adding CACHE_SAVE filter for %s", r->uri);
 
-/* add cache_save filter to cache this request */
-ap_add_output_filter_handle(cache_save_filter_handle, NULL, r,
-r->connection);
+/*
+ * Add cache_save filter to cache this request. Choose
+ * the correct filter by checking if we are a subrequest
+ * or not.
+ */
+if (r->main) {
+ap_log_error(APLOG_MARK, APLOG_DEBUG, APR_SUCCESS,
+ r->server,
+ "Adding CACHE_SAVE_SUBREQ filter for %s",
+ r->uri);
+
ap_add_output_filter_handle(cache_save_subreq_filter_handle,
+NULL, r, r->connection);
+}
+else {
+ap_log_error(APLOG_MARK, APLOG_DEBUG, APR_SUCCESS,
+ r->server, "Adding CACHE_SAVE filter for %s",
+ r->uri);
+ap_add_output_filter_handle(cache_save_filter_handle, 
+NULL, r, r->connection);
+}
 
 ap_log_error(APLOG_MARK, APLOG_DEBUG, APR_SUCCESS, r->server,
  "Adding CACHE_REMOVE_URL filter for %s", 
@@ -189,9 +206,21 @@
  * filters have been set. So lets run the insert_filter hook.
  */
 ap_run_insert_filter(r);
-ap_add_output_filter_handle(cache_out_filter_handle, NULL,
-r, r->connection);
 
+/*
+ * Add cache_out filter to serve this request. Choose
+ * the correct filter by checking if we are a subrequest
+ * or not.
+ */
+if (r->main) {
+ap_add_output_filter_handle(cache_out_subreq_filter_handle, NULL,
+r, r->connection);
+}
+else {
+ap_add_output_filter_handle(cache_out_filter_handle, NULL,
+r, r->connection);
+}
+
 /* kick off the filter stack */
 out = apr_brigade_create(r->pool, r->connection->bucket_alloc);
 rv = ap_pass_brigade(r->output_filters, out);
@@ -1146,23 +1175,56 @@
 /* cache filters 
  * XXX The cache filters need to run right after the handlers and before
  * any other filters. Consider creating AP_FTYPE_CACHE for this purpose.
- * Make them AP_FTYPE_CONTENT for now.
- * XXX ianhH:they should run AFTER all the other content filters.
+ *
+ * Depending on the type of request (subrequest / main request) they
+ * need to be run before AP_FTYPE_CONTENT_SET / after AP_FTYPE_CONTENT_SET
+ * filters. Thus create two filter handles for each type:
+ * cache_save_filter_handle / cache_out_filter_handle to be used by
+ * main requests and
+ * cache_save_subreq_filter_

Re: Should exist: mod_log_dbus?

[Ondrej Sury]

On Wed, 2005-10-12 at 09:54 -0400, Brian Akins wrote:
> Andy Armstrong wrote:
> 
> > I'm prepared to do some work on such a module but I don't want to do 
> > it if there's some obvious alternative I'm missing. Is this something 
> > that might be useful? Is there something out there already that I've 
> > missed?
> 
> This may not be the most appropriate place to discuss it, but I am 
> willing to help do some work as well.  From the quick overview of dbus I 
> just read, it doesn't look too complicated to do.

Hi Brian,

I think this is another good example where one could use of your
mod_log_config with providers patch.  It should be fairy easy to write
provider for something like dbus.

Ondrej.
-- 
Ondrej Sury <[EMAIL PROTECTED]>


signature.asc
Description: This is a digitally signed message part

Re: [pre-release] 2.0.55 *candidate* available for testing

[Ondrej Sury]

On Thu, 2005-10-13 at 14:44 +0200, Graham Leggett wrote:
[...]

Sounds reasonable...

> Sometimes however, someone might need a bleeding edge feature not 
> offered by a distro, but they might not want to clutter up their
> system 
> with "custom" install trees. The ASF packages serve the needs of this 
> group of people. 

Then I would suggest to provide _clean_ .tar.gz not including any .spec
or whatever and *also* provide .src.rpm package for bleeding edge
testers.  How does it sound to you?

Ondrej.
-- 
Ondrej Sury <[EMAIL PROTECTED]>


signature.asc
Description: This is a digitally signed message part

Re: [PATCH] Handle subrequests to non local resources correctly

[Graham Leggett]

Ruediger Pluem said:

> So I created a patch which defines four filter handles instead of two:
>
> CACHE_OUT / CACHE_SAVE as AP_FTYPE_CONTENT_SET+1 filters and
> CACHE_OUT_SUBREQ / CACHE_SAVE_SUBREQ as AP_FTYPE_CONTENT_SET-1 filters
>
> Depending on the type of request the patch now inserts either the
> AP_FTYPE_CONTENT_SET+1
> or the AP_FTYPE_CONTENT_SET-1 filter.
>
> Comments / Thoughts?

I've seen the location of the cache filters move up and down the chain for
a long time now, and I wonder if this moving up and down is such a good
idea.

My original intention when I put together the CACHE_OUT and CACHE_SAVE
filters was that they ran first and last on the filter chain.

In other words, mod_cache could be thought of as a completely separate
HTTP/1.1 proxy cache "bolted on" to the frontend of httpd, but as
independant as possible of the httpd server itself.

HTTP/1.1 already caters for transparent frontend proxies and describes the
behaviour when there is authn and authz, variants of the same URL, etc.
Bolting the cache onto the frontend means that as long as the cache
follows the RFC, it will work predictably and securely, as there are
enough transparent caching proxies out there to show that HTTP/1.1 works.

Over time, for various reasons, the cache code has moved further down the
stack. This has complicated the cache code, because now instead of purely
following HTTP/1.1's spec, it must now take into account extra details
like special authn handling, variant handling, etc.

I would prefer to see a solution to this problem that moves closer to the
HTTP/1.1 spec for transparent proxies.

Regards,
Graham
--

Re: [pre-release] 2.0.55 *candidate* available for testing

[Graham Leggett]

Ondrej Sury said:

> Then I would suggest to provide _clean_ .tar.gz not including any .spec
> or whatever and *also* provide .src.rpm package for bleeding edge
> testers.  How does it sound to you?

In other words a return to where we started way back when, ie no spec file
at all, and various vendors offering their own competing and incompatible
spec files.

I am not sure what problem you are trying to solve by removing the specfile?

Regards,
Graham
--

Re: Notice of Intent: T&R 1.3.34

[Jim Jagielski]

On Oct 11, 2005, at 11:48 PM, Glenn Strauss wrote:


On Mon, Oct 10, 2005 at 10:54:36AM -0400, Jim Jagielski wrote:


I will be T&R'ing 1.3.34 On Tues or Weds



May I humbly request inclusion of a patch I wrote almost a year ago?
http://issues.apache.org/bugzilla/show_bug.cgi?id=31858
|31858|New|Maj|2004-10-22|regular expression matching broken on amd64
It is not a feature request; it fixes a crashing bug on AMD64.
This has been discussed, has been validated, and is included in
Gentoo (http://bugs.gentoo.org/show_bug.cgi?id=70177) and probably
other distributions.



Just another reminder to PLEASE test the regex changes
so I can T&R 1.3.34. Unless I hear otherwise, I will
tag 1.3.34 later on tonight.

Re: svn commit: r320832 - /httpd/httpd/branches/1.3.x/Announcement

[William A. Rowe, Jr.]

[EMAIL PROTECTED] wrote:

Author: jim
Date: Thu Oct 13 10:56:53 2005
New Revision: 320832

URL: http://svn.apache.org/viewcvs?rev=320832&view=rev
Log:
Announcement tweaks - sync with httpd-dist.

Modified:
httpd/httpd/branches/1.3.x/Announcement


Did we decide to scrap the Announcement file from the tarball to match
with httpd-2.0 and simplify the job of syncing Announcement after we
actually roll the tarball?

I've updated the NW and Win32 builds to not copy Announcement, and did
not see anywhere in the Unix build which copied it to the install path.

Bill

Re: [pre-release] 2.0.55 *candidate* available for testing

[Sander Temme]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On Oct 10, 2005, at 9:35 AM, William A. Rowe, Jr. wrote:


Sander Temme wrote:


On Oct 9, 2005, at 9:42 PM, William A. Rowe, Jr. wrote:

The httpd-2.0.55 candidate, including win32 source .zip and   
installers*,


As of 17:59 CEST (15 minutes ago), 2.0.55 is running on   
www.apache.org. Please report any anomalies.




Ack, starting clock with 72 hours to GA, contingent upon an absence
of problem reports (specificially regressions).


Six more cores since the last update of mod_mbox. Then twenty more  
appeared with exactly the same timestamp: probably some bot pounding  
the site.


Quick story: all the cores I've analyzed are mod_mbox crashes. None  
in other parts of httpd.


+1 for GA based on running for 72 hours on www.apache.org without  
crashes in the distributed code.


S.

Brief analysis of some of the cores follows:

/raid1/httpd-cores/core.5885

#0  mbox_mime_decode_body (p=0x0, cte=CTE_NONE, body=0x0, len=0) at  
mod_mbox_mime.c:290
#1  0x2100 in mbox_mime_get_body (p=0x602509c8,  
m=0x60063130) at mod_mbox_mime.c:299
#2  0x2100d2e0 in mbox_static_message (r=0x60250a30,  
f=0x601ed530) at mod_mbox_out.c:1151
#3  0x21008ca0 in mbox_file_handler (r=0x60250a30) at  
mod_mbox_file.c:231
#4  0x40035f90 in ap_run_handler (r=0x60250a30) at  
config.c:153
#5  0x40036f70 in ap_invoke_handler (r=0x60250a30) at  
config.c:317
#6  0x4002fb00 in ap_process_request (r=0x60250a30)  
at http_request.c:226
#7  0x40024bf0 in ap_process_http_connection  
(c=0x601db350) at http_core.c:233
#8  0x4004db00 in ap_run_process_connection  
(c=0x601db350) at connection.c:43
#9  0x40032910 in child_main (child_num_arg=27976) at  
prefork.c:610
#10 0x40032be0 in make_child (s=0x60047788, slot=360)  
at prefork.c:704
#11 0x40033180 in perform_idle_server_maintenance (p=0x6) at  
prefork.c:839
#12 0x40033fc0 in ap_mpm_run (_pconf=0x6000bc68,  
plog=0x60042298, s=0x0) at prefork.c:863
#13 0x40041f60 in main (argc=2, argv=0x6fffb3e8) at  
main.c:618


(gdb) print r->unparsed_uri
$2 = 0x60251f00 "/mod_mbox/httpd-users/200310.mbox/%3CBAY2- 
[EMAIL PROTECTED]"


/raid1/httpd-cores/core.28450

#0  get_base_uri (r=0x60215748) at mod_mbox.c:197
#1  0x21007a10 in get_base_path (r=0x60215748) at  
mod_mbox.c:178
#2  0x2100cfa0 in mbox_static_message (r=0x602155d0,  
f=0x601f87b8) at mod_mbox_out.c:1051
#3  0x21008ca0 in mbox_file_handler (r=0x602155d0) at  
mod_mbox_file.c:231
#4  0x40035f90 in ap_run_handler (r=0x602155d0) at  
config.c:153
#5  0x40036f70 in ap_invoke_handler (r=0x602155d0) at  
config.c:317
#6  0x4002fb00 in ap_process_request (r=0x602155d0)  
at http_request.c:226
#7  0x40024bf0 in ap_process_http_connection  
(c=0x601db530) at http_core.c:233
#8  0x4004db00 in ap_run_process_connection  
(c=0x601db530) at connection.c:43
#9  0x40032910 in child_main (child_num_arg=27976) at  
prefork.c:610
#10 0x40032be0 in make_child (s=0x60047788, slot=29)  
at prefork.c:704
#11 0x40033180 in perform_idle_server_maintenance (p=0x1) at  
prefork.c:839
#12 0x40033fc0 in ap_mpm_run (_pconf=0x0,  
plog=0x60042298, s=0x0) at prefork.c:863
#13 0x40041f60 in main (argc=2, argv=0x6fffb3e8) at  
main.c:618


(gdb) print r->unparsed_uri
$1 = 0x0
(gdb) print r->header_only
$3 = 1

/raid1/httpd-cores/core.19623

#0  get_base_uri (r=0x60213778) at mod_mbox.c:197
#1  0x21007a10 in get_base_path (r=0x60213778) at  
mod_mbox.c:178
#2  0x2100cfa0 in mbox_static_message (r=0x60213600,  
f=0x60224958) at mod_mbox_out.c:1051
#3  0x21008ca0 in mbox_file_handler (r=0x60213600) at  
mod_mbox_file.c:231
#4  0x40035f90 in ap_run_handler (r=0x60213600) at  
config.c:153
#5  0x40036f70 in ap_invoke_handler (r=0x60213600) at  
config.c:317
#6  0x4002fb00 in ap_process_request (r=0x60213600)  
at http_request.c:226
#7  0x40024bf0 in ap_process_http_connection  
(c=0x601db530) at http_core.c:233
#8  0x4004db00 in ap_run_process_connection  
(c=0x601db530) at connection.c:43
#9  0x40032910 in child_main (child_num_arg=27976) at  
prefork.c:610
#10 0x40032be0 in make_child (s=0x60047788, slot=185)  
at prefork.c:704
#11 0x40033180 in perform_idle_server_maintenance (p=0x2) at  
prefork.c:839
#12 0x40033fc0 in ap_mpm_run (_pconf=0x0,  
plog=0x60042298, s=0x0) at prefork.c:863
#13 0x40041f60 in main (argc=2, argv=0x6fffb3e8) at  
main.c:618


There are quite a few of these. Her

Re: svn commit: r320832 - /httpd/httpd/branches/1.3.x/Announcement

[Jim Jagielski]

Yes, it will be scrapped from the tarball, but not the tagged tree.

William A. Rowe, Jr. wrote:
> 
> [EMAIL PROTECTED] wrote:
> > Author: jim
> > Date: Thu Oct 13 10:56:53 2005
> > New Revision: 320832
> > 
> > URL: http://svn.apache.org/viewcvs?rev=320832&view=rev
> > Log:
> > Announcement tweaks - sync with httpd-dist.
> > 
> > Modified:
> > httpd/httpd/branches/1.3.x/Announcement
> 
> Did we decide to scrap the Announcement file from the tarball to match
> with httpd-2.0 and simplify the job of syncing Announcement after we
> actually roll the tarball?
> 
> I've updated the NW and Win32 builds to not copy Announcement, and did
> not see anywhere in the Unix build which copied it to the install path.
> 
> Bill
> 


-- 
===
 Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
   "If you can dodge a wrench, you can dodge a ball."

Re: async write completion prototype

[Greg Ames]

Brian Pane wrote:

On Oct 10, 2005, at 12:01 AM, Paul Querna wrote:


If the content has already been generated, why add the overhead of  
the context switch/sending to another thread?  Can't the same event  
thread do a non-blocking write?


Once it finishes writing, then yes, we do require a context-switch  to 
another thread to do logging/cleanup.


I am mostly thinking about downloading a 1 gig file with the  current 
pattern against a slow client.  A non-blocking write might  only do 
~64k at a time, and causing 1 gig/64k context switches,  which seems 
less than optimal.



If I had to choose, I'd rather do the context switches than devote a
thread (and the associated stack space) to the connection until
the writes are finished--especially if the server is delivering a
thousand 1GB files to slow clients concurrently.

However, it's probably possible to have _both_ a high ratio
of connections to threads (for scalability) and a low ratio of
context switches to megabytes delivered (for efficiency).
The Event MPM currently has to do a lot of context switching
because it detects events in one thread and processes them
in another.  If we add async write completion to the
Leader/Followers MPM (or incorporate a leader/follower
thread model into Event), it should reduce the context
switches considerably.


this is interesting to me because Brian Atkins recently reported that 
the event MPM was much slower. 
http://mail-archives.apache.org/mod_mbox/httpd-dev/200509.mbox/[EMAIL PROTECTED]


it would be nice to hear more details, but I assume that this means 
event is burning more CPU for a given workload rather than some kind of 
extra latency bug.  we know that event has more context switching than 
worker when keepalives are in use but pipelining is not, and async write 
completion will add to it.  I suppose we should profile event and worker 
and compare profiles in case there's some other unexpected CPU burner 
out there.


if context switch overhead is really the culprit, how do we reduce it? 
if I recall correctly, leader/follower sort of plays tag and the next 
thread that's It gets to be the listener.  I can see that running the 
request processing on the same thread that does the accept would be more 
cache friendly, and it might save some of the current queuing logic. 
but doesn't this have about the same amount of pthread library/scheduler 
overhead to "tag" the new listener and dispatch it as we have now waking 
up worker threads?


another brainstorm is to use a short keepalive timeout, like 200ms*, on 
the worker thread.  if it pops, turn the connection over to the event 
pollset using the remaining KeepAliveTimeout and give up the worker 
thread.


Greg

*200ms - the idea is to use something just big enough to cover most 
network round trip times, so we catch the case where the browser sends 
the next request immediately after getting our response.

Re: async write completion prototype

[Greg Ames]

Greg Ames wrote:

this is interesting to me because Brian Atkins recently reported that 


s/Atkins/Akins/   sorry, Brian

Greg

Re: async write completion prototype

[Brian Akins]

Greg Ames wrote:

this is interesting to me because Brian Atkins recently reported that 
the event MPM was much slower. 
http://mail-archives.apache.org/mod_mbox/httpd-dev/200509.mbox/[EMAIL PROTECTED] 


No "t" in my last name :)


Basically, I was referring to the overall hits a box could serve per second.

with 512 concurrent connections and about an 8k file, 2.1 with worker 
served about 22k request/second.  event served about 14k.


It's been a while since I did the test, and I'm too busy for the next 
few days to re-run them.



--
Brian Akins
Lead Systems Engineer
CNN Internet Technologies

Re: svn commit: r320823 - in /httpd/mod_mbox/trunk/module-2.0: mod_mbox_index.c mod_mbox_search.c

[André Malo]

* [EMAIL PROTECTED] wrote:

> Author: pquerna
> Date: Thu Oct 13 10:42:36 2005
> New Revision: 320823
>
> URL: http://svn.apache.org/viewcvs?rev=320823&view=rev
> Log:
> For all handlers, Deny all non-GET requests.

Whoo! I've just investigated a bit about r->allowed and found, that 
r->allowed is never evaluated later in 2.x.x! Seems, at one point this was 
changed to the r->allowed_methods interface, but even the standard modules 
weren't updated. That's bad, bad, bad.

If nobody tells me that I'm missing something, I'm gonna create a patch 
right now.

nd
-- 
"Das Verhalten von Gates hatte mir bewiesen, dass ich auf ihn und seine
beiden Gefährten nicht zu zählen brauchte" -- Karl May, "Winnetou III"

Im Westen was neues: 

Re: async write completion prototype

[Greg Ames]

Brian Akins wrote:

Basically, I was referring to the overall hits a box could serve per 
second.


with 512 concurrent connections and about an 8k file, 2.1 with worker 
served about 22k request/second.  event served about 14k.


do you recall if CPU cycles were maxed out in both cases?

thanks,
Greg

Re: async write completion prototype

[Brian Akins]

Greg Ames wrote:


do you recall if CPU cycles were maxed out in both cases?


Yes.

--
Brian Akins
Lead Systems Engineer
CNN Internet Technologies

Re: mpm_winnt incompatible and broken behavior on restart

[Jeff White]

Ivan Zhakov wrote:


We have Apache/Subversion server
under Windows Server 2003.



From Bill Stoddard



I think the few Win32 developers
here (myself included) always had
this on their list of 'todo's'. The
Windows MPM needs to be enhanced
to reliably support multiple child processes
and when that's done, this will be fixed
'for free'.


Perhaps 'for free' see how IIS7
handles this or perhaps just host
the whole web server or just parts
of IIS7 within Apache or within any
other (perhaps Subversion) Windows
Vista process?

IIS 7.0 Beta:
IIS Hostable Web Core Reference
http://msdn.microsoft.com/library/en-us/IIS_70_WebExtSDK/html/d9d5406e-edef-ab14-c78a-711f70d5cda2.asp

IIS 7.0 Beta:
Internet Information Services (IIS) 7.0 SDK
http://msdn.microsoft.com/library/en-us/IIS_70_WebExtSDK/html/6c07a4d0-1bf0-45d3-8178-25df76e6740c.asp

IIS 7.0 Beta: IIS 7.0 Operations Guide (IIS 7.0 Beta 1)
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/iis7/Ops/9a90c800-3f09-4a3f-87b0-caae34076aca.mspx


Jeff

Re: [pre-release] 2.0.55 *candidate* available for testing

[William A. Rowe, Jr.]

Thank you everyone for testing, especially the infrateam for picking
this up on Ajax and really stressing it under mod_mbox (in spite of
a few more fixes required to mbox's mime processing :)

Although the site is updated, starting the clock on the announce till
early tomorrow aftn (america time) so that our proxies start to catch up.

FYI I staged, did not svn up the 1.3.34 announce site work for Jim's
behalf - so we are 1/2 there.

Docs team; feel free to ressurect or add Announcement2.0.txt/.html.lang,
and even Announcement1.3.txt/.html.lang - the security notes in 2.0 I'm
sure are quite a bit of work to translate.  These are all in the
https://svn.apache.org/repos/asf/httpd/httpd/dist/ repository.  You're
also welcome to work up Announcement2.1-beta.txt/.html.lang if you like.

Note I've eliminated the Announcement's "German and Japanese
translations are available" - and rather indicate that additional
translations may become available so that users bother to check,
should they require a native translation.

Bill

Apache HTTP Server 1.3.34 prerelease tarballs

[Jim Jagielski]

Look for the Apache HTTP Server 1.3.34 prerelease tarballs in:

   http://httpd.apache.org/dev/dist/

Please test :)

strange behavior of Redirect on ajax

[Roy T. Fielding]

I just tried to add

Redirect Permanent /dist/jakarta/tomcat 
http://www.apache.org/dist/tomcat/tomcat


to a .htaccess on ajax and the prefix match/replace didn't work.
I had to replace it with

RedirectMatch Permanent /dist/jakarta/tomcat(.*)$ 
http://www.apache.org/dist/tomcat/tomcat$1


to get the intended results.

It makes me wonder if all Redirect directives are broken. :(

Roy

Re: async write completion prototype

[Brian Pane]

I think one contributor to the event results is an issue that Paul  
Querna

pointed out on #httpd-dev the other day: apr_pollset_remove runs in O(n)
time with n descriptors in the pollset.

Brian

On Oct 13, 2005, at 11:36 AM, Brian Akins wrote:


Greg Ames wrote:


this is interesting to me because Brian Atkins recently reported  
that the event MPM was much slower. http://mail- 
archives.apache.org/mod_mbox/httpd-dev/200509.mbox/% 
[EMAIL PROTECTED]




No "t" in my last name :)


Basically, I was referring to the overall hits a box could serve  
per second.


with 512 concurrent connections and about an 8k file, 2.1 with  
worker served about 22k request/second.  event served about 14k.


It's been a while since I did the test, and I'm too busy for the  
next few days to re-run them.



--
Brian Akins
Lead Systems Engineer
CNN Internet Technologies