Re: cvs commit: httpd-2.0/server util_filter.c
[EMAIL PROTECTED] wrote: rbb 01/08/26 23:00:51 Modified:.CHANGES include util_filter.h modules/ssl mod_ssl.c ssl_engine_io.c server util_filter.c util_filter.c httpd-2.0\server\util_filter.c(205) : warning C4098: 'ap_remove_input_filter' : 'void' function returns a value httpd-2.0\server\util_filter.c(210) : warning C4098: 'ap_remove_output_filter' : 'void' function returns a value -- Sebastian Bergmann Measure Traffic Usability http://sebastian-bergmann.de/http://phpOpenTracker.de/
location walk before directory walk
Just out of curiosity, would it be easier if, for 2.0, we fixed the original bogosity of location walk by running it first, before directory walk, and simply forbid its use within .htaccess? That would eliminate most of the issues regarding wasted time spent checking directories for things that are only virtual namespaces. Roy
Re: cvs commit: httpd-2.0/server core.c request.c
On Sun, Aug 26, 2001 at 05:10:17AM -, [EMAIL PROTECTED] wrote:
core_a = ap_get_module_config(a-elt, core_module);
core_b = ap_get_module_config(b-elt, core_module);
-if (IS_SPECIAL(core_a)) {
- if (!IS_SPECIAL(core_b)) {
- return 1;
- }
+
+if (core_a-r core_b-r) {
+return -1;
}
-else if (IS_SPECIAL(core_b)) {
- return -1;
+else if (core_a-r core_b-r) {
+return 1;
}
Does this bit mean that regex-based sections won't run in config-file
order, but in order of their positions in the heap?
-else {
- /* we know they're both not special */
- if (core_a-d_components core_b-d_components) {
- return -1;
- }
- else if (core_a-d_components core_b-d_components) {
- return 1;
- }
+if (core_a-d_components core_b-d_components) {
+return -1;
+}
+else if (core_a-d_components core_b-d_components) {
+return 1;
}
-/* Either they're both special, or they're both not special and have the
- * same number of components. In any event, we now have to compare
- * the minor key. */
+/* They have the same number of components, we now have to compare
+ * the minor key to maintain the original order.
+ */
return a-orig_index - b-orig_index;
}
Re: dependencies
The *real* question is whether buildconf or configure should figure out dependencies or not. configure is probably a Bad Thing because there isn't much reason for end-users to have the dependencies recomputed every time they run the darn thing. buildconf is really the place to do it. *If* we want to impose dependency generation and use on all developers. That would only work if it is sufficient to include only the non-os-specific dependencies, since buildconf is run pre-tarball. The worst thing we could do is propagate OS or configuration-specific dependencies. Personally, I'd rather we just add and maintain the relevant dependencies manually within the Makefile.in files, with only the config-dependent dependencies appended by configure. And never run make depend again. Roy
Re: Someunknown block
William A. Rowe, Jr. [EMAIL PROTECTED] writes: ... passes the config parsing with flying colors, even when it's meaningless. maybe the issue is location-dependent? I just added Someunknown block /Someunknown to the very top of my file and get [trawick@rdu88-250-106 httpd-2.0]$ ./httpd -t Syntax error on line 1 of /home/trawick/apacheinst/conf/httpd.conf: Invalid command 'Someunknown', perhaps mis-spelled or defined by a module not included in the server configuration Is there a reason we are allowing unrecognized/unparsed blocks into the config? bug I would expect we would want to error out. yes -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: location walk before directory walk
From: Roy T. Fielding [EMAIL PROTECTED] Sent: Monday, August 27, 2001 1:54 AM Just out of curiosity, would it be easier if, for 2.0, we fixed the original bogosity of location walk by running it first, before directory walk, and simply forbid its use within .htaccess? That would eliminate most of the issues regarding wasted time spent checking directories for things that are only virtual namespaces. I think the patches to date accomplish that. If you have a virtual namespace, and register a map_to_storage hook as HOOK_MIDDLE, and it simply returns OK, then the second Location walk won't even be walked again. Bill
Re: cvs commit: httpd-2.0/server core.c request.c
From: Barrie Slaymaker [EMAIL PROTECTED]
Sent: Monday, August 27, 2001 3:22 AM
On Sun, Aug 26, 2001 at 05:10:17AM -, [EMAIL PROTECTED] wrote:
core_a = ap_get_module_config(a-elt, core_module);
core_b = ap_get_module_config(b-elt, core_module);
-if (IS_SPECIAL(core_a)) {
- if (!IS_SPECIAL(core_b)) {
- return 1;
- }
+
+if (core_a-r core_b-r) {
+return -1;
}
-else if (IS_SPECIAL(core_b)) {
- return -1;
+else if (core_a-r core_b-r) {
+return 1;
}
Does this bit mean that regex-based sections won't run in config-file
order, but in order of their positions in the heap?
They always have run in this order,
1. Non regex expressions first, then all regex'es
2. By the number of components (so '/', then '/foo', then '/foo/bar')
3. By their order in the configuration file.
The only thing this patch changes is that 'specials' (such as proxy: entries)
cannot be in Directory sections. The proxy: entries can now be configured
with Proxy sections. And my patch to run Proxy entries doesn't sort them
at all (I have posted the question to the modproxy-dev list, if we even want
them sorted by any critera.)
Bill
[Fwd: Patch for building support programs]
Since this appears to have been eaten by apache's listserver, i'll resend...
Original Message
Subject: Patch for building support programs
From: Thom May [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Hi,
Building support programs currently is easy to break under most
conditions. If I change apachectl.in like so:
-HTTPD='@prefix@/bin/@progname@'
+HTTPD='@sbindir@/@progname@'
where sbindir is defined to configure as exec_prefix/sbin, the end result
after a configure run is that apachectl looks like:
HTTPD='${exec_prefix}/sbin/apache
which is fine for a Makefile, but not so useful for a perl script. As
part of the debian packages build, the configure script is patched so
that program generation is handled by a separate perl script,
build-progs.pl
I have attached the perl script as a patch for your review, and then
hopefully inclusion into the build process.
Cheers,
-Thom
--- apache2/build/buildprogs.pl.origFri Aug 24 00:48:01 2001
+++ apache2/build/buildprogs.pl Fri Aug 24 00:47:22 2001
@@ -0,0 +1,114 @@
+#!/usr/bin/perl
+# Copyright (C) Thom May [EMAIL PROTECTED] 2001
+# Licensed under the BSD License, without the advertising clause. +#
Bugs - can't handle multiple replaces on one line, unless it's of the
form:
+# @ONE@/@TWO@
+# I have no idea what happens if it finds something it doesn't know
about...
+#
+
+my $buildir=`pwd`;
+chomp($buildir);
+die Usage: $0 srcdir file1 [file2...]\n
+ if ($#ARGV 0);
+
+my $srcdir = shift(@ARGV);
+my $config_vars = $srcdir/config_vars.mk;
+read_config();
+
+while ($file = shift(@ARGV))
+{
+ if ($file =~ /^([^\.]*)\.in/){
+ $infile = $;
+ $outfile = $1;
+ }
+ else
+ {
+ $outfile = $file;
+ $infile = $file.in;
+ }
+ # now we read the file, substitute the necessary bits, and close the
file again.
+ # fortunately the nice way actually works!
+ $perlbin = `which perl`;
+ chomp($perlbin);
+ open(INFILE, $infile) || die Couldn't open $infile - $!\n;
+ open(OUTFILE, $outfile) || die Couldn't open $outfile for
writing - $!\n;
+ while(INFILE)
+ {
+ if(/\@([\w]*)\@(\/\@([\w]*)\@)?/g)
+ {
+ if($3)
+ {
+ $replace1 = $$1;
+ $replace2 = $$3;
+ $replace1 = replace($replace1);
+ $replace2 = replace($replace2);
+ s/\@([\w]*)\@(\/\@([\w]*)\@)?/$replace1\/
$replace2/;
+ print OUTFILE;
+ }
+ else
+ {
+ $replace1 = $$1;
+ $replace1 = replace($replace1);
+ s/\@([\w]*)\@/$replace1/;
+print OUTFILE;
+ }
+
+ } else
+ {
+ print OUTFILE;
+ }
+ }
+ close(OUTFILE);
+ close(INFILE);
+}
+# read in config_vars.mk, grab the relevant bits, dump them to
variables. +sub read_config
+{
+ die Couldn't find config variables!\n if (! -f $config_vars);
+ open(CFG_VARS,$config_vars)||die Couldn't open $config_vars, $!
\n;
+ my @configs = CFG_VARS;
+ close(CFG_VARS);
+ foreach(@configs) #read out the relevant bits of config_vars.mk
+ {
+ if(!/^#/ !/^$/ /=/)
+ {
+ chomp();
+ my ($lv,$rv) = split(/=/,$_,2);
+ $lv = trim($lv);
+ $rv = trim($rv);
+ $_=$lv;
+ $$lv=$rv;
+ }
+ # unfortunately we aren't going to know the prefix until some
arbitrary point
+ # thus we are going to have to rewrite the variables at write time.
+ #
this is pretty nasty :/
+ }
+ $exec_prefix=replace($exec_prefix);
+}
+
+sub replace
+{
+ $temp = $_[0];
+ if($temp =~ /^(\$\(exec_prefix\))\/(.*)/)
+ {
+ $temp = $exec_prefix/$2;
+ }
+ else
+ {
+ if ($temp =~ /^(\$\(prefix\))\/(.*)/)
+ {
+ $temp = $prefix/$2;
+ }
+ }
+ $temp =~ s/\/\/(.*)/\/$1/gi;
+
+ $temp;
+}
+
+sub trim
+{
+ $_=$_[0];
+ s/^\040+//g;
+ s/\040+$//g;
+ $_;
+}
Re: odd content length goings on
Marc Slemko [EMAIL PROTECTED] writes:
Erm... why would we be unable to read the data?
I have the exact same CGI. If I have it output, for example, 6k of data
there is never a content-length. If I have it output, for example, 10k of
data, there is.
is there some buffering or pausing going on which affects the
length=6k case? I get a content-length for lengths up to 32K or so.
-anylength.pl-
#!/usr/local/bin/perl -w
BEGIN
{
use CGI::Carp qw(fatalsToBrowser);
}
use strict;
use CGI;
my $q = new CGI;
my $offset = $q-param('length');
my $i;
if (!$offset)
{
die Yo! I need an offset!;
}
print Content-type: text/html\n\n;
$i = 0;
while ($offset 0)
{
if (($i % 50) eq 0)
{
print \n;
}
else
{
print 1;
}
++$i;
--$offset;
}
--
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: location walk before directory walk
From: Roy T. Fielding [EMAIL PROTECTED] Sent: Monday, August 27, 2001 1:54 AM Just out of curiosity, would it be easier if, for 2.0, we fixed the original bogosity of location walk by running it first, before directory walk, and simply forbid its use within .htaccess? That would eliminate most of the issues regarding wasted time spent checking directories for things that are only virtual namespaces. I think the patches to date accomplish that. If you have a virtual namespace, and register a map_to_storage hook as HOOK_MIDDLE, and it simply returns OK, then the second Location walk won't even be walked again. I think what Roy is suggesting is that we eliminate the second LocationWalk. I am a tentative +1 on his suggestion. And it doesn't make sense to allow Location directives in .htaccess files (use of Location implies we are not serving out of the file system anyway). I don't see any problems right off hand... Bill
Re: cvs commit: httpd-2.0/server core.c request.c
On Mon, Aug 27, 2001 at 07:22:52AM -0500, William A. Rowe, Jr. wrote:
From: Barrie Slaymaker [EMAIL PROTECTED]
Sent: Monday, August 27, 2001 3:22 AM
On Sun, Aug 26, 2001 at 05:10:17AM -, [EMAIL PROTECTED] wrote:
core_a = ap_get_module_config(a-elt, core_module);
core_b = ap_get_module_config(b-elt, core_module);
-if (IS_SPECIAL(core_a)) {
- if (!IS_SPECIAL(core_b)) {
- return 1;
- }
+
+if (core_a-r core_b-r) {
+return -1;
}
-else if (IS_SPECIAL(core_b)) {
- return -1;
+else if (core_a-r core_b-r) {
+return 1;
}
Does this bit mean that regex-based sections won't run in config-file
order, but in order of their positions in the heap?
They always have run in this order,
1. Non regex expressions first, then all regex'es
2. By the number of components (so '/', then '/foo', then '/foo/bar')
3. By their order in the configuration file.
#3 is why I responded. This patch seems to change that nice behavior;
like regexes are sorted by their addresses (the value of core_{a,b}-r)
rather than their position (core_{a,b}-orig_index).
The only thing this patch changes is that 'specials' (such as proxy: entries)
cannot be in Directory sections. The proxy: entries can now be configured
with Proxy sections. And my patch to run Proxy entries doesn't sort them
at all (I have posted the question to the modproxy-dev list, if we even want
them sorted by any critera.)
Yup, I like the Proxy section stuff a lot.
As far as sorting, it would be nice for everyone's sanity if
(Directory|Location|Proxy)(Match)? sections were sorted using as
similar a logic as possible. Given the number of incremental directives
that are starting to crop up, sort order is going to be very important
to config stability. By incremental directives, I mean directives where
previous settings are modified by directives occuring in later directory
sections, like the (unintuitively named, IMHO) Set{Input,Output}Filter
and like external modules do (see AxKit's directives for a lot of
these).
Just the ramblings of someone who's had to explain the current state of
affairs and watch the heads shaking...
- Barrie
P.S. I also like the suggestion that went by to make the first
ap_location_walk stick and do away with the second. It's much more
intuitive to me: URIs get run through the Location mill first, then
(Directory and Files) or (Proxy) section. Seems like the need for
the duplicate ap_location_walk()s should be much less now that PRosy
sections exist.
Re: cvs commit: httpd-2.0/server core.c request.c
On Monday 27 August 2001 06:22, Bill Stoddard wrote: From: Bill Stoddard [EMAIL PROTECTED] Sent: Sunday, August 26, 2001 11:48 AM On Sat, Aug 25, 2001 at 11:43:19PM -, [EMAIL PROTECTED] wrote: wrowe 01/08/25 16:43:19 Modified:.CHANGES include http_request.h modules/http http_core.c http_protocol.c http_request.c mod_core.h server core.c request.c Log: Introduce the map_to_storage hook, which allows modules to bypass the directory_walk and file_walk for non-file requests. TRACE How is this different from the translate_name hook? Your new hook and the translate_name are both about translating URLs into the backend storage. Why was this new one added? (did I miss some discussion somewhere?) And if so, then why does translate_name stick around? Sounds similar to the quick_handler hook as well. It does? Then you need to find a clue. quick_handler should have been axed from the outset, and now that this handler allows a non-filesystem request to be handled properly, it really should be gone. map_to_storage is definitely not the same as quick_handler. But quick_handler does have a use so it stays in. Actually, they are closer than you might think. quick_handler's purpose is to allow requests to be served as quickly as possible. It skips a lot of phases of the request to accomplish that. If map_to_storage is tweaked a bit, it can accomplish the same thing. Basically, the map_to_storage function that succeeds would tell the server how many of the hooks that follow map_to_storage that it should skip before the handler phase. This has a couple of advantages over quick_handler, the first one being that it is more general, and the second that it means we go back to having one location that data is sent to the network. If that change is made to map_to_storage, then I would be with OtherBill, and suggest that quick_handler should be removed. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: location walk before directory walk
On Mon, 27 Aug 2001, Ryan Bloom wrote: On Monday 27 August 2001 05:54, Bill Stoddard wrote: From: Roy T. Fielding [EMAIL PROTECTED] Sent: Monday, August 27, 2001 1:54 AM Just out of curiosity, would it be easier if, for 2.0, we fixed the original bogosity of location walk by running it first, before directory walk, and simply forbid its use within .htaccess? That would eliminate most of the issues regarding wasted time spent checking directories for things that are only virtual namespaces. Just a question, but what if you are using .htaccess files to partition things up for virtual hosts? For example, I am running a server and both Roy and Bill have sites on it. Since I am a control freak, I refuse to give either access to httpd.conf, but because I am also lazy, I have allowed both to use .htaccess files. In that case, don't people need to be able to put localtion directives inside of .htaccess files? Either I am missing something, or there is an error in the docs; the 1.3 docs state that Location is not allowed in .htaccess. Joshua.
[PATCH] Apache 1.3.21-dev for NetWare builds (5)
Hi all,
here is the biggest issue I am experiencing with my builds of the Apache
for NetWare using the GNU stuff:
5. CodeWarrior bitfields alignment (compatibility) issue
The Apache binaries produced by the CodeWarrior (currently the only one
officially supported tool for NetWare builds of the Apache server) are
affected by an alignment issue (bitfields). It causes incompatibility
between the core and external modules built with other tools (GNU stuff,
Watcom, ...).
There is a structure called "uri_components" defined in src/include/util_uri.h:
typedef struct {
// ...
unsigned short port;
unsigned is_initialized:1;
unsigned dns_looked_up:1;
unsigned dns_resolved:1;
} uri_components;
... and it is used within a structure called "request_rec" (widely used
by the modules and the core) defined in src/include/httpd.h:
struct request_rec {
//...
uri_components parsed_uri; /* components of uri, dismantled */
void *per_dir_config; /* Options set in config files, etc. */
void *request_config; /* Notes on *this* request */
//...
};*
*An "unsigned short port" element is incorrectly aligned to 4 bytes (should be 2
bytes) and the following set of bitfields is incorrectly aligned to 4 bytes (should by
1 byte) by CW compiler = the size of "uri_components" is different (+5 bytes than
usual, e.g. if compiling with gcc), offset to bitfield (the same for all its
components) also differ.
Most problems (abends) occur if accessing something below a "parsed_uri" structure
element (typically a "per_dir_config" used by a "ap_get_module_config" macro in some
modules).
For more understanding: Here is the latest posting from Guenter Knauf
taken from the "support.apachebuilds" forum on nntp.wiserlabz.com news
server, where this issue was discussed:
Hi all,
the following (unofficial) answer I received from Metrowerks support;
I hope that this is NOT the final word..
=
Hi,
I just got this in, and it looks to be the final word I am going to get. So
why don't you look this over, (I've left it verbatim) and tell me if this is
acceptable to you. It looks just like and implementation dependent item
where you should not count on it working the same.
Ron
=
I agree this is an undesirable way for bitfields to be aligned, but this
agrees with MSVC, upon which we based the bitfield layout. (In MSVC the
smallest we can make the struct is 4 bytes!)
I think the way to work around this is to change the bitfield base type to
"unsigned char". The type of the bitfield is used in determining how it is
aligned; thus, using a smaller type will require a smaller alignment.
P.S. Remind the developers that this style of bitfield alignment is neither
"correct" or "incorrect" (unless something really bad is happening such as
bitfields overlapping each other or other members of the struct) since
neither ANSI nor C99 define how compilers implement bitfields. This is
strictly the vendor's decision.
I suggest to fix the problem as described (patch attached), even if it will be
considered as CodeWarrior's bug (and fixed, then) by Metrowerks or not. I've
detailedly analyzed the issue and I see no way how to stay backwardly compatible with
this issue, so all binaries for NetWare platform (Apache core+modules from CVS sources
and all "3rd party" external modules produced with CW) should be re-built after the
fix (if it will be commited) - it will not be possible to mix new NLMs with older
Apache core or modules.
I have tested the fix with CW 5.3 and gcc 2.95.3 and it seems that alignment of
problematic structures is the same (it differs from current status quo, of course).
The change in the source file shared on all platforms is requested, so verification on
these ones will be needed. I don't expect problems (no change in alignment) on
platforms where the GNU stuff is used (gcc). Thanks.
Regards,
Pavel
--- util_uri.h.orig Mon Feb 26 16:49:32 2001
+++ util_uri.h Mon Aug 27 15:44:41 2001
@@ -106,10 +106,10 @@
unsigned short port; /* The port number, numeric, valid only if port_str !=
NULL */
-unsigned is_initialized:1;
+unsigned char is_initialized:1;
-unsigned dns_looked_up:1;
-unsigned dns_resolved:1;
+unsigned char dns_looked_up:1;
+unsigned char dns_resolved:1;
} uri_components;
Re: cvs commit: httpd-2.0/modules/http http_protocol.c
On Sun, Aug 26, 2001 at 05:20:40PM -0700, Greg Stein wrote: On Sun, Aug 26, 2001 at 03:18:41PM -0700, Ryan Bloom wrote: On Sunday 26 August 2001 12:54, Doug MacEachern wrote: On Sun, 26 Aug 2001, Marc Slemko wrote: hang on, is this about keepalives or chunked encoding? both. the check always fails because ap_content_length_filter has set content length before ap_set_keepalive is called. the right fix would probably be to check http/1.1-oneness eariler and remove (or not add) the ap_content_length_filter if r-chunked. Can't do that. The content-length filter always computes the full content length, even if it isn't put in the response. That way, we can log it correctly. I'd prefer to log it as 0 or somesuch, rather than buffer the response just for the sake of logging. Not of a particular mind here, but it *does* seem expensive to buffer just for logging's sake. Thoughts? I'd like to see ap_read_request and ap_set_sub_req_protocol set r-clength to -1 or AP_CONTENT_LENGTH_UNSET and use that to distinguish an empty response from one that hasn't had its content length set. I'm screwing around with some packaging filters which end up computing the content length while they're at it. Unless I remove ap_content_length_filter from the filter chain, it re-walks the brigade. I'm a little leary of removing it by name (CONTENT-LENGTH) as it's not a constant and may change from version to version. I'd like to just leave it alone, set the clength, and count on it to if (f-r-clength != AP_CONTENT_LENGTH_UNSET) return ap_pass_brigade(f-next, b) Reasonable? Crazy? -- -eric ([EMAIL PROTECTED]) Feel free to forward this message to any list for any purpose other than email address distribution.
Re: cvs commit: httpd-2.0/server core.c request.c
It does? Then you need to find a clue. quick_handler should have been axed from the outset, and now that this handler allows a non-filesystem request to be handled properly, it really should be gone. map_to_storage is definitely not the same as quick_handler. But quick_handler does have a use so it stays in. Actually, they are closer than you might think. quick_handler's purpose is to allow requests to be served as quickly as possible. It skips a lot of phases of the request to accomplish that. If map_to_storage is tweaked a bit, it can accomplish the same thing. Basically, the map_to_storage function that succeeds would tell the server how many of the hooks that follow map_to_storage that it should skip before the handler phase. This has a couple of advantages over quick_handler, the first one being that it is more general, and the second that it means we go back to having one location that data is sent to the network. If that change is made to map_to_storage, then I would be with OtherBill, and suggest that quick_handler should be removed. Give me a while to experiment with getting mod_cache working with map_to_storage. I've been considering moving quick_handler to after the first Location walk, which brings the functionality I am looking for very close to map_to_storage. We are meeting in the middle :-) Bill
Re: location walk before directory walk
I think what Roy is suggesting is that we eliminate the second LocationWalk. I am a tentative +1 on his suggestion. And it doesn't make sense to allow Location directives in .htaccess files (use of Location implies we are not serving out of the file system anyway). I don't see any problems right off hand... Just a question, but what if you are using .htaccess files to partition things up for virtual hosts? For example, I am running a server and both Roy and Bill have sites on it. Since I am a control freak, I refuse to give either access to httpd.conf, but because I am also lazy, I have allowed both to use .htaccess files. In that case, don't people need to be able to put localtion directives inside of .htaccess files? Perhaps. I'm taking a very narrow view of the purpose for Location directives (which may or may not be right). If we are serving content from the file system, then we should use File/Directory et. al. directives. If the content we are serving is not backed by a file system, then we should use Location directives. And the two should not overlap. Given those conditions, should the site admin (bill/roy) be able to control (via Location directives) any aspect of how a back-end, non file system based content generator is configured? Examples? Bill
Re: recommanded configure for 2.0.24 ?
Justin Erenkrantz wrote: On Sun, Aug 26, 2001 at 02:19:54AM +0200, Gomez Henri wrote: Yes, on Linux prefork is selected by default. threaded seems to works fine, but perchild is no more useable since mod_ssl failed to build. Yeah, but there are outstanding issues with threaded MPM that make me leery of recommending threaded for end-users until we resolve them. Henry, Last time I checked, worker had a problem handling more than one concurrent connection per process. So I would advise you to test worker vs. threaded before you make a decision. Greg
Re: cvs commit: httpd-2.0/server core.c request.c
From: Barrie Slaymaker [EMAIL PROTECTED]
Sent: Monday, August 27, 2001 8:22 AM
On Mon, Aug 27, 2001 at 07:22:52AM -0500, William A. Rowe, Jr. wrote:
From: Barrie Slaymaker [EMAIL PROTECTED]
Sent: Monday, August 27, 2001 3:22 AM
On Sun, Aug 26, 2001 at 05:10:17AM -, [EMAIL PROTECTED] wrote:
core_a = ap_get_module_config(a-elt, core_module);
core_b = ap_get_module_config(b-elt, core_module);
-if (IS_SPECIAL(core_a)) {
- if (!IS_SPECIAL(core_b)) {
- return 1;
- }
+
+if (core_a-r core_b-r) {
+return -1;
}
-else if (IS_SPECIAL(core_b)) {
- return -1;
+else if (core_a-r core_b-r) {
+return 1;
}
Does this bit mean that regex-based sections won't run in config-file
order, but in order of their positions in the heap?
They always have run in this order,
1. Non regex expressions first, then all regex'es
2. By the number of components (so '/', then '/foo', then '/foo/bar')
3. By their order in the configuration file.
#3 is why I responded. This patch seems to change that nice behavior;
like regexes are sorted by their addresses (the value of core_{a,b}-r)
rather than their position (core_{a,b}-orig_index).
OUTCH! It does, thank you!
if ((core_a-r != NULL) (core_b-r != NULL)) {
return -1;
}
else if ((core_a-r != NULL) (core_b-r != NULL)) {
return 1;
}
does that look better :-? I'll commit as soon as someone tells me sanity (or at least
my abuse of pointers as bools) is cured :)
Bill
The only thing this patch changes is that 'specials' (such as proxy: entries)
cannot be in Directory sections. The proxy: entries can now be configured
with Proxy sections. And my patch to run Proxy entries doesn't sort them
at all (I have posted the question to the modproxy-dev list, if we even want
them sorted by any critera.)
Yup, I like the Proxy section stuff a lot.
As far as sorting, it would be nice for everyone's sanity if
(Directory|Location|Proxy)(Match)? sections were sorted using as
similar a logic as possible. Given the number of incremental directives
that are starting to crop up, sort order is going to be very important
to config stability. By incremental directives, I mean directives where
previous settings are modified by directives occuring in later directory
sections, like the (unintuitively named, IMHO) Set{Input,Output}Filter
and like external modules do (see AxKit's directives for a lot of
these).
Just the ramblings of someone who's had to explain the current state of
affairs and watch the heads shaking...
- Barrie
P.S. I also like the suggestion that went by to make the first
ap_location_walk stick and do away with the second. It's much more
intuitive to me: URIs get run through the Location mill first, then
(Directory and Files) or (Proxy) section. Seems like the need for
the duplicate ap_location_walk()s should be much less now that PRosy
sections exist.
Re: [Fwd: [Spread-users] send text to spread group from command line?]
On Monday 27 August 2001 07:10, Ben Laurie wrote: Ryan Bloom wrote: I would. But I have a very good reason. We already have the same basic idea, but done a bit safer. Basically, we have a log_error hook, but it is run at the end of log_error_core, so that we are sure that we always get the error in the error_log, even if we don't get it anyplace else. There are some minor tweaks that should be made to the current hook, because right now it actually sends out too much information, like the timestamp. But, it should handle what George wants just fine. Heh! Good point! When did that go in? I added it in 2.0.19. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
[Fwd: [Spread-users] send text to spread group from command line?]
Would anyone object to me committing this? Cheers, Ben. -- http://www.apache-ssl.org/ben.html There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff Hi Ben, I have a patch to httpd-2_0_18-alpha that does what I'm looking for. Don't know the appropriate place to submit it. I've attached it on the off chance direct-to-you is ok. Best, George 1024D/1100A5A0/1370 F70A 9365 96C9 2F5E 56C2 B2B9 262F 1100 A5A0 error_log.patch
Re: [Fwd: [Spread-users] send text to spread group from command line?]
I would. But I have a very good reason. We already have the same basic idea, but done a bit safer. Basically, we have a log_error hook, but it is run at the end of log_error_core, so that we are sure that we always get the error in the error_log, even if we don't get it anyplace else. There are some minor tweaks that should be made to the current hook, because right now it actually sends out too much information, like the timestamp. But, it should handle what George wants just fine. Ryan On Monday 27 August 2001 06:54, Ben Laurie wrote: Would anyone object to me committing this? Cheers, Ben. -- http://www.apache-ssl.org/ben.html There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff X-Sieve: cmu-sieve 2.0 Return-Path: [EMAIL PROTECTED] Received: from mailgate.algroup.co.uk (mailgate.algroup.co.uk [194.128.162.5]) by scuzzy.ben.algroup.co.uk (Postfix) with SMTP id 7371B2E9A9 for [EMAIL PROTECTED]; Mon, 27 Aug 2001 03:34:05 + (GMT) Received: (qmail 1174 invoked by uid 1002); 27 Aug 2001 03:33:25 - Delivered-To: [EMAIL PROTECTED] Received: (qmail 23543 invoked from network); 27 Aug 2001 03:33:25 - Received: from longsword.omniti.com ([EMAIL PROTECTED]) by mailgate.algroup.co.uk with SMTP; 27 Aug 2001 03:33:25 - Received: from [216.5.117.60] (helo=maya) by longsword.omniti.com with esmtp (Exim 3.22 #2) id 15bDA2-0007Ua-00; Sun, 26 Aug 2001 23:34:02 -0400 Date: Sun, 26 Aug 2001 23:34:01 -0400 From: George Schlossnagle [EMAIL PROTECTED] Content-Type: multipart/alternative; boundary=Apple-Mail-965253019-1 Subject: Re: [Spread-users] send text to spread group from command line? Cc: [EMAIL PROTECTED] To: Ben Laurie [EMAIL PROTECTED] X-Mailer: Apple Mail (2.388) In-Reply-To: [EMAIL PROTECTED] Mime-Version: 1.0 (Apple Message framework v388) Message-Id: [EMAIL PROTECTED] Hi Ben, I have a patch to httpd-2_0_18-alpha that does what I'm looking for. Don't know the appropriate place to submit it. I've attached it on the off chance direct-to-you is ok. Best, George 1024D/1100A5A0/1370 F70A 9365 96C9 2F5E 56C2 B2B9 262F 1100 A5A0 Attachment missing Content-Type: text/plain; charset=us-ascii; name=Attachment: 1 Content-Transfer-Encoding: 7bit Content-Description: Content-Type: application/octet-stream; charset=us-ascii; name=error_log.patch Content-Transfer-Encoding: quoted-printable Content-Description: -- __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: cvs commit: httpd-2.0/server core.c request.c
From: Ryan Bloom [EMAIL PROTECTED] Sent: Monday, August 27, 2001 8:41 AM map_to_storage is definitely not the same as quick_handler. But quick_handler does have a use so it stays in. Actually, they are closer than you might think. quick_handler's purpose is to allow requests to be served as quickly as possible. It skips a lot of phases of the request to accomplish that. If map_to_storage is tweaked a bit, it can accomplish the same thing. It's not going to be tweaked (you security sloths, you :) We need to look at each of the hook phases, and figure out how a module can selectively bypass that hook, when it should, and why. I'll probably start a paper detailing how the current Apache system exposes hooks, and what's the harm in using/bypassing those hooks. Quick_handler bypasses everything. We ignore the client's headers, the server's configuration, everything. Frankly, quick_handler is not Apache, and anyone who writes a quick_handler hack and calls it a module for 'Apache' is full of sh*t. Powered by the Apr/Apache MPM/load manager is more like it (that isn't badness, that's just reality.) Basically, the map_to_storage function that succeeds would tell the server how many of the hooks that follow map_to_storage that it should skip before the handler phase. No... I thought long and hard about that, and I dislike it. It's full of opportunities to mess up security and bypass things you didn't expect (in v. 2.1 or whenever.) hook_to_storage (named wrong, we agree) is the trap to walk a set of dir_config's that are customized for the module. 50% of the modules serve files, so they _don't_ hook this call. 40% of the modules invent content in a yes or no sort of way. They are generally driven by the Location block, so that block can contain their access restrictions. They don't want us to hook up any extra dir_config's, so they may hook this call and just return OK. 10% of the modules (e.g. proxy, perhaps a database-driven content store) don't have 'files' in the traditional sense, but they want a tree mapping of restrictions, and it won't correspond to our Directory Files sections in a 1:1 manner. For those modules, they can hook and replace dir_walk/file_walk with their own (e.g. proxy_walk.) This has a couple of advantages over quick_handler, the first one being that it is more general, and the second that it means we go back to having one location that data is sent to the network. Yes - it's definately a design decision that an author needs to be aware of. We aren't working well enough with too many modules as it is (take mod_autoindex/negotation/mime security reports, or tomcat security reports.) We don't want module authors to suffer from a slow model. But we don't want them wandering too far out of the fold, until they fall in the pit that so many modules have landed in. If that change is made to map_to_storage, then I would be with OtherBill, and suggest that quick_handler should be removed. I'm about to suggest that as well, but I don't think we can do so until we optimize our whole server. That is, I just optimized the two-pass Location parsing. Unless the URI is remapped (a significant context change that requires rewalking the location), or we have been mapped to a virtual server with a different set of locations (they probably wern't inherited from the base server), then we will do zero or one directory merges. Zero merges if no module modified the per_dir_config since we left it (no dir/file/proxy walk), or one merge if we see someone reset per_dir_config, so we will overlay it. Almost every hook can be a bit more optimized this way. I'm most concerned about subreq and internal redirect mechansims, and will continue to work to assure 1. they do the same thing, even in different contexts, and 2. they rely on the original request as much as possible to drop cpu/filesystem load. An example ... dir_walk can do the same thing as location_walk does. If we already walked the first 3 directory elements, and come back with a subreq for a subdir, why duplicate the work? We have some great opportunities here for cleaner, smaller and faster code. Then I'll suggest dropping quick_handler, and have a document to back up my position :) Bill
Re: location walk before directory walk
From: Joshua Slive [EMAIL PROTECTED] Sent: Monday, August 27, 2001 8:57 AM On Mon, 27 Aug 2001, Ryan Bloom wrote: On Monday 27 August 2001 05:54, Bill Stoddard wrote: From: Roy T. Fielding [EMAIL PROTECTED] Sent: Monday, August 27, 2001 1:54 AM Just out of curiosity, would it be easier if, for 2.0, we fixed the original bogosity of location walk by running it first, before directory walk, and simply forbid its use within .htaccess? That would eliminate most of the issues regarding wasted time spent checking directories for things that are only virtual namespaces. Just a question, but what if you are using .htaccess files to partition things up for virtual hosts? For example, I am running a server and both Roy and Bill have sites on it. Since I am a control freak, I refuse to give either access to httpd.conf, but because I am also lazy, I have allowed both to use .htaccess files. In that case, don't people need to be able to put localtion directives inside of .htaccess files? Either I am missing something, or there is an error in the docs; the 1.3 docs state that Location is not allowed in .htaccess. Correct. The array of Location directives is stored in the virtual server. Changes to the virtual host, or the uri itself, both necessitate rewalking the Location list. That's why location_walk is invoked twice.
Re: [Fwd: [Spread-users] send text to spread group from command line?]
Hmmm... I undesrtand you concern. It might be nice to have a 'panic' type log. Still, implementing a RUN_FIRST hook has the benefit of saying 'Try and log however you want, and if you fail, then fall onto core_logging'. Sometimes people don't want redundancy in their logs, sometimes you want to be guaranteed you have one copy of it somewhere without always having 3 copies. The specific instance I see for this is error logging via spread. It would be swell to be able to just dump error logs to spread, and write to disk if and only if there was a problem (in which case, you have the logging module return a DECLINED and then you log to disk.) Implementing the hook where I did also allows you to add a run-first panic log hook that always logs fatal errors to disk, and returns DECLINED to let the rest of the handlers run. Thoughts? George - Original Message - From: Ryan Bloom [EMAIL PROTECTED] To: George Schlossnagle [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, August 27, 2001 11:08 AM Subject: Re: [Fwd: [Spread-users] send text to spread group from command line?] On Monday 27 August 2001 07:26, George Schlossnagle wrote: For better or for worse, there are alot of folks who would prefer to turn off local error logging completely, and do all logging via a distributed mechanism. Actually, I was also considering whether it would be better to do a AP_IMPLEMENT_HOOK_RUN_FIRST, so that you can /truly/ override the internal logging mechanism safely. Would that fit people's safety/flexibility concerns better? There are still ways to disable the logging to the disk, but I am concerned that if you allow modules to run before the core's error logging mechanism, then you take the very real chance that you will never see any logs, ever. Also, this should not be a RUN_FIRST, because that removes any redundancy in the system at all. Ryan __ Ryan Bloom[EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: recommanded configure for 2.0.24 ?
Greg Ames [EMAIL PROTECTED] writes: Last time I checked, worker had a problem handling more than one concurrent connection per process. So I would advise you to test worker vs. threaded before you make a decision. I just tried worker with Aaron Bannert's fixes applied. It is finally working reasonably for me with many concurrent connections. -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: [PATCH] Apache 1.3.21-dev for NetWare builds (5)
From: "Pavel Novy" [EMAIL PROTECTED] Sent: Monday, August 27, 2001 9:08 AM I suggest to fix the problem as described (patch attached), even if it will be considered as CodeWarrior's bug (and fixed, then) by Metrowerks or not. I've detailedly analyzed the issue and I see no way how to stay backwardly compatible with this issue, so all binaries for NetWare platform (Apache core+modules from CVS sources and all "3rd party" external modules produced with CW) should be re-built after the fix (if it will be commited) - it will not be possible to mix new NLMs with older Apache core or modules. I have tested the fix with CW 5.3 and gcc 2.95.3 and it seems that alignment of problematic structures is the same (it differs from current status quo, of course). The change in the source file shared on all platforms is requested, so verification on these ones will be needed. I don't expect problems (no change in alignment) on platforms where the GNU stuff is used (gcc). Thanks. Pavel, I'm sorry, I cannot see this code change for the 1.3 generation. I sympathize that the implementors on the Netware platform refuse to see eye to eye (or even attempt to bring some sort of compatiblity options to the table.) And the unsigned char solution is very slow, compared to integer manipulation, so I'm not sure we would choose that anyways. Please bring this discussion to Apache 2.0. I know Brad Nicholes and company at Novell are working hard to support Apache 2.0. This implementation will be a far more secure and stable platform than the 1.3 hybrid/threaded implementations (win32/os2/netware etc.) If we direct our energies at solving the problem there, and we can agree on a mechansim, I see this issue being resolved in Apache 2.0. Bill --- util_uri.h.orig Mon Feb 26 16:49:32 2001 +++ util_uri.h Mon Aug 27 15:44:41 2001 @@ -106,10 +106,10 @@ unsigned short port; /* The port number, numeric, valid only if port_str != NULL */ -unsigned is_initialized:1; +unsigned char is_initialized:1; -unsigned dns_looked_up:1; -unsigned dns_resolved:1; +unsigned char dns_looked_up:1; +unsigned char dns_resolved:1; } uri_components;
Re: [Fwd: [Spread-users] send text to spread group from command line?]
On Monday 27 August 2001 08:14, George Schlossnagle wrote: Hmmm... I undesrtand you concern. It might be nice to have a 'panic' type log. Still, implementing a RUN_FIRST hook has the benefit of saying 'Try and log however you want, and if you fail, then fall onto core_logging'. Sometimes people don't want redundancy in their logs, sometimes you want to be guaranteed you have one copy of it somewhere without always having 3 copies. I understand this. The problem is that a RUN_FIRST removes any level of redundancy. A RUN_ALL allows the server admin to setup as much redundancy as they want. If you want to log to just spread, then set ErrorLog to /dev/null. If it is a RUN_FIRST, and I want to log to spread, and send an SNMP trap whenever I get a critical error, how do I do that? This needs to be a RUN_ALL. Ryan The specific instance I see for this is error logging via spread. It would be swell to be able to just dump error logs to spread, and write to disk if and only if there was a problem (in which case, you have the logging module return a DECLINED and then you log to disk.) Implementing the hook where I did also allows you to add a run-first panic log hook that always logs fatal errors to disk, and returns DECLINED to let the rest of the handlers run. Thoughts? George - Original Message - From: Ryan Bloom [EMAIL PROTECTED] To: George Schlossnagle [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, August 27, 2001 11:08 AM Subject: Re: [Fwd: [Spread-users] send text to spread group from command line?] On Monday 27 August 2001 07:26, George Schlossnagle wrote: For better or for worse, there are alot of folks who would prefer to turn off local error logging completely, and do all logging via a distributed mechanism. Actually, I was also considering whether it would be better to do a AP_IMPLEMENT_HOOK_RUN_FIRST, so that you can /truly/ override the internal logging mechanism safely. Would that fit people's safety/flexibility concerns better? There are still ways to disable the logging to the disk, but I am concerned that if you allow modules to run before the core's error logging mechanism, then you take the very real chance that you will never see any logs, ever. Also, this should not be a RUN_FIRST, because that removes any redundancy in the system at all. Ryan __ Ryan Bloom[EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] -- -- __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: [Fwd: [Spread-users] send text to spread group from command line?]
Makes sense. Still it would be nice to be able to run core_error_log conditionally. So that I can send my logs to spread, send an SNMP trap and not log to disk, because I confirmed I succeeded in one of the first two. That's why I think it should be run last (except perhaps a fatal level error logger at the head of the bunch). The point is that I don't want to unconditionally send logs to /dev/null, but only if I succeeded in sending them with my user-defined method. - Original Message - From: Ryan Bloom [EMAIL PROTECTED] To: George Schlossnagle [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, August 27, 2001 11:33 AM Subject: Re: [Fwd: [Spread-users] send text to spread group from command line?] On Monday 27 August 2001 08:14, George Schlossnagle wrote: Hmmm... I undesrtand you concern. It might be nice to have a 'panic' type log. Still, implementing a RUN_FIRST hook has the benefit of saying 'Try and log however you want, and if you fail, then fall onto core_logging'. Sometimes people don't want redundancy in their logs, sometimes you want to be guaranteed you have one copy of it somewhere without always having 3 copies. I understand this. The problem is that a RUN_FIRST removes any level of redundancy. A RUN_ALL allows the server admin to setup as much redundancy as they want. If you want to log to just spread, then set ErrorLog to /dev/null. If it is a RUN_FIRST, and I want to log to spread, and send an SNMP trap whenever I get a critical error, how do I do that? This needs to be a RUN_ALL. Ryan The specific instance I see for this is error logging via spread. It would be swell to be able to just dump error logs to spread, and write to disk if and only if there was a problem (in which case, you have the logging module return a DECLINED and then you log to disk.) Implementing the hook where I did also allows you to add a run-first panic log hook that always logs fatal errors to disk, and returns DECLINED to let the rest of the handlers run. Thoughts? George - Original Message - From: Ryan Bloom [EMAIL PROTECTED] To: George Schlossnagle [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, August 27, 2001 11:08 AM Subject: Re: [Fwd: [Spread-users] send text to spread group from command line?] On Monday 27 August 2001 07:26, George Schlossnagle wrote: For better or for worse, there are alot of folks who would prefer to turn off local error logging completely, and do all logging via a distributed mechanism. Actually, I was also considering whether it would be better to do a AP_IMPLEMENT_HOOK_RUN_FIRST, so that you can /truly/ override the internal logging mechanism safely. Would that fit people's safety/flexibility concerns better? There are still ways to disable the logging to the disk, but I am concerned that if you allow modules to run before the core's error logging mechanism, then you take the very real chance that you will never see any logs, ever. Also, this should not be a RUN_FIRST, because that removes any redundancy in the system at all. Ryan __ Ryan Bloom[EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] -- -- __ Ryan Bloom[EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: cvs commit: httpd-2.0/server core.c request.c
map_to_storage is definitely not the same as quick_handler. But quick_handler does have a use so it stays in. Actually, they are closer than you might think. quick_handler's purpose is to allow requests to be served as quickly as possible. It skips a lot of phases of the request to accomplish that. If map_to_storage is tweaked a bit, it can accomplish the same thing. It's not going to be tweaked (you security sloths, you :) We need to look at each of the hook phases, and figure out how a module can selectively bypass that hook, when it should, and why. I'll probably start a paper detailing how the current Apache system exposes hooks, and what's the harm in using/bypassing those hooks. Quick_handler bypasses everything. We ignore the client's headers, the server's configuration, everything. Frankly, quick_handler is not Apache, and anyone who writes a quick_handler hack and calls it a module for 'Apache' is full of sh*t. Powered by the Apr/Apache MPM/load manager is more like it (that isn't badness, that's just reality.) So tell us how you -really- feel :-) I am looking at the map_to_storage hook to see how it works. Stay tuned. The quick_handler hook was named after (and is used by) Mike Abbott's quick cache, an -Apache- module. It is a specialized hook to serve a specialized purpose: serving web pages as fast as possible from a user space resident cache. And it can be used without compromising the security of the server. Bill
Re: [PATCH] Apache 1.3.21-dev for NetWare builds (5)
Hi Bill, Please bring this discussion to Apache 2.0. I know Brad Nicholes and company at Novell are working hard to support Apache 2.0. This implementation will be a far more secure and stable platform than the 1.3 hybrid/threaded implementations (win32/os2/netware etc.) If we direct our energies at solving the problem there, and we can agree on a mechansim, I see this issue being resolved in Apache 2.0. at this time we cannot discuss anything about NetWare and 2.0 because the NetWare OS dependent files are not in CVS tree so we cannot build a 2.0 NetWare version... Guenter.
Re: cvs commit: httpd-2.0/server core.c request.c
From: Bill Stoddard [EMAIL PROTECTED] Sent: Monday, August 27, 2001 10:54 AM map_to_storage is definitely not the same as quick_handler. But quick_handler does have a use so it stays in. Actually, they are closer than you might think. quick_handler's purpose is to allow requests to be served as quickly as possible. It skips a lot of phases of the request to accomplish that. If map_to_storage is tweaked a bit, it can accomplish the same thing. Quick_handler bypasses everything. We ignore the client's headers, the server's configuration, everything. Frankly, quick_handler is not Apache, and anyone who writes a quick_handler hack and calls it a module for 'Apache' is full of sh*t. Powered by the Apr/Apache MPM/load manager is more like it (that isn't badness, that's just reality.) So tell us how you -really- feel :-) Let me fine-tune my statement. Modules that use quick_handler bypass the _user's_ expectations, and our documented behavior. If this is ok for a given module, and is well documented, then fine. I feel that nothing frustrates me more, personally, than to follow docs and observe a different result than was doumented. That's why I turned Greg to the Location /Limit combinations for DAV, since they have odd side-effects. I am looking at the map_to_storage hook to see how it works. Stay tuned. The quick_handler hook was named after (and is used by) Mike Abbott's quick cache, an -Apache- module. It is a specialized hook to serve a specialized purpose: serving web pages as fast as possible from a user space resident cache. And it can be used without compromising the security of the server. The best example is loading the mod_proxy/proxy_http combination. I have to say that the patch to mod_proxy was about as clear as I've ever written. It will give you a terrific feel for what can be done :) From an optimization perspective, see the Location patch from last night, it shows what you can do with pre-cached per_dir_config's, you would just need to use config wide pools and voila, mod_file_cache can have preconstructed per_dir_configs too. I'll be modifying Directory to also observe any preconstruction, so all internal_internal_redirect and subreq entities can go back through directory_walk without consuming significant CPU. Bill
r-assbackwards
Folks, I have a two simple questions. One; does assbackwards simply refer to HTTP/0.9? Two; why are we trying to support HTTP/0.9 in the year 2001? How many pre HTTP/1.0 clients are out there to support? I know the proxy team would like to remove some XXX deal with r-assbackwards comments in their code :) Bill
Re: [PATCH] Apache 1.3.21-dev for NetWare builds (5)
Guenter, About 90% of the NetWare specific changes for the APR layer have been checked into CVS. I am still working on the final 10% (which is usually the hardest). It may not look that way only because we were able to piggy back most of the NetWare code on Unix. This is a good thing for us because it means that we didn't have to rewrite a lot of code. I still have to organize some of the platform specific header files and get some of the kinks worked out in the project file, but we are close to having and APR layer that should work with the HTTPD server. In theory as soon as we get APR complete, there shouldn't be any additional work necessary to make Apache 2.0 run. Of course a theory is just a theory until it is proven and we won't have the proof until APR is complete for NetWare :). thanks, Brad [EMAIL PROTECTED] Monday, August 27, 2001 10:05:23 AM Hi Bill, Please bring this discussion to Apache 2.0. I know Brad Nicholes and company at Novell are working hard to support Apache 2.0. This implementation will be a far more secure and stable platform than the 1.3 hybrid/threaded implementations (win32/os2/netware etc.) If we direct our energies at solving the problem there, and we can agree on a mechansim, I see this issue being resolved in Apache 2.0. at this time we cannot discuss anything about NetWare and 2.0 because the NetWare OS dependent files are not in CVS tree so we cannot build a 2.0 NetWare version... Guenter.
Re: odd content length goings on
On 27 Aug 2001, Jeff Trawick wrote: Marc Slemko [EMAIL PROTECTED] writes: Erm... why would we be unable to read the data? I have the exact same CGI. If I have it output, for example, 6k of data there is never a content-length. If I have it output, for example, 10k of data, there is. is there some buffering or pausing going on which affects the length=6k case? I get a content-length for lengths up to 32K or so. What platform? I'm FreeBSD / prefork. As I said, ap_set_content_length gets called, but it just doesn't end up being sent. marcs@deathbed:~$ GET -e -d http://localhost:8080/~marcs/tests/anylength.cgi?length=8166 Connection: close Date: Mon, 27 Aug 2001 16:39:49 GMT Server: Apache/2.0.25-dev (Unix) Content-Type: text/html; charset=ISO-8859-1 marcs@deathbed:~$ GET -e -d http://localhost:8080/~marcs/tests/anylength.cgi?length=8167 Connection: close Date: Mon, 27 Aug 2001 16:39:54 GMT Server: Apache/2.0.25-dev (Unix) Content-Length: 8167 Content-Type: text/html; charset=ISO-8859-1 marcs@deathbed:~$ GET -e -d http://localhost:8080/~marcs/tests/anylength.cgi?length=1 Connection: close Date: Mon, 27 Aug 2001 16:40:46 GMT Server: Apache/2.0.25-dev (Unix) Content-Type: text/html; charset=ISO-8859-1 Hrmph. The truss of a CGI request looks pretty scary...
Re: r-assbackwards
On Mon, 27 Aug 2001, William A. Rowe, Jr. wrote: Folks, I have a two simple questions. One; does assbackwards simply refer to HTTP/0.9? yes. Two; why are we trying to support HTTP/0.9 in the year 2001? How many pre HTTP/1.0 clients are out there to support? because we can? there aren't many, but people probably have lots of random custom code that uses 0.9 requests to just grab something from a server.
make install fails
Hi all, The latest CVS of Apache v2.0 fails on make install like this: Installing configuration files Installing HTML documents Installing error documents /bin/sh: cd: docs/error: No such file or directory make[1]: *** [install-error] Error 1 make[1]: Leaving directory `/home/minfrin/src/apache/sandbox/ldap/httpd-2.0' make: *** [install-recursive] Error 1 Regards, Graham -- - [EMAIL PROTECTED]There's a moon over Bourbon Street tonight... S/MIME Cryptographic Signature
Re: r-assbackwards
William A. Rowe, Jr. [EMAIL PROTECTED] writes: Two; why are we trying to support HTTP/0.9 in the year 2001? How many pre HTTP/1.0 clients are out there to support? telnet :) -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: make install fails
Graham Leggett [EMAIL PROTECTED] writes: Hi all, The latest CVS of Apache v2.0 fails on make install like this: Installing configuration files Installing HTML documents Installing error documents /bin/sh: cd: docs/error: No such file or directory don't you have httpd-2.0/docs/error/* on your system? -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
RE: make install fails
It's probably worth to check out the 'entire' httpd-2.0 tree from CVS afresh onto a new location.. A cvs up did not checkout / create the docs/error directory for me.. -Madhu -Original Message- From: Jeff Trawick [mailto:[EMAIL PROTECTED]] Sent: Monday, August 27, 2001 10:03 AM To: [EMAIL PROTECTED] Subject: Re: make install fails Graham Leggett [EMAIL PROTECTED] writes: Hi all, The latest CVS of Apache v2.0 fails on make install like this: Installing configuration files Installing HTML documents Installing error documents /bin/sh: cd: docs/error: No such file or directory don't you have httpd-2.0/docs/error/* on your system? -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: make install fails
Jeff Trawick wrote: The latest CVS of Apache v2.0 fails on make install like this: Installing configuration files Installing HTML documents Installing error documents /bin/sh: cd: docs/error: No such file or directory don't you have httpd-2.0/docs/error/* on your system? Nope - but it does exist in my pristine tree. Seems CVS is doing odd things - when I do a cvs update in my sandbox tree it doesn't pull the error directory. Methinks it's time to build the tree from scratch again... Regards, Graham -- - [EMAIL PROTECTED]There's a moon over Bourbon Street tonight... S/MIME Cryptographic Signature
Re: make install fails
MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) [EMAIL PROTECTED] writes: It's probably worth to check out the 'entire' httpd-2.0 tree from CVS afresh onto a new location.. A cvs up did not checkout / create the docs/error directory for me.. It sounds like you folks are missing the -d option to cvs update... From the man page: Use the -d option to create any directories that exist in the repository if they're missing from the working directory. (Nor- mally, update acts only on directories and files that were already enrolled in your working directory.) This is useful for updating directories that were created in the repository since the initial checkout... Consider something like this for ~/.cvsrc: update -Pd diff -u -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: [Fwd: [Spread-users] send text to spread group from command line?]
On Monday 27 August 2001 09:12, Ben Laurie wrote: Ryan Bloom wrote: On Monday 27 August 2001 07:14, Ben Laurie wrote: Ryan Bloom wrote: I would. But I have a very good reason. We already have the same basic idea, but done a bit safer. Basically, we have a log_error hook, but it is run at the end of log_error_core, so that we are sure that we always get the error in the error_log, even if we don't get it anyplace else. There are some minor tweaks that should be made to the current hook, because right now it actually sends out too much information, like the timestamp. But, it should handle what George wants just fine. I don't see why this is any safer than George's proposal, though - indeed, IMO, his is more elegant since it makes it easier for someone who really wants to disable the standard error logging to be able to do so. Ah, but the point of my patch was to make that harder to do, not easier. :-) My thinking was that error logs are everything. If you lose a log, then there is a problem. If a module seg faults during the error_log, then you may not ever know that there was a problem. This way, we are sure the have the log on the disk regardless of what else happens. If you want to disable the disk- based log, just log to /dev/null. So make the core hook run first - I still think George's was better. So go ahead and change it to the new model. I didn't veto, I just said don't commit it wholesale, because we already have that feature. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: [patch] apxs
Committed. Thanks. Ryan On Monday 27 August 2001 03:03, Stas Bekman wrote: I've started from the point where apxs was failing with the error: /home/stas/httpd-2.0/bin/apxs apxs:Error: Invalid query string `SHLTCFLAGS' because my httpd-2.0/build/config_vars.mk had: SHLTCFLAGS = I was fixing it and while doing that I've refactored some of the code: So this patch - allows empty $val from httpd-2.0/build/config_vars.mk - make code more perlish. - read and parse the config file only once - use a hash instead of array for the list of internal config vars to test against - added -h option (just print usage) - wrapped numerous print STDERR calls into a simpler error() and notice() subs - simplified some of the logic in if's using perl constructs. I didn't know how to extensively test whether I didn't break anything. BTW, according to the apxs manpage, the following command % /home/stas/httpd-2.0/bin/apxs -q -S PREFIX=bar INCLUDEDIR should print: /bar/include while it prints: /home/stas/httpd-2.0/include which seems to be wrong. This happens in the current apxs version, my patch doesn't change it. __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: cvs commit: httpd-2.0/modules/mappers mod_negotiation.c
[EMAIL PROTECTED] writes: trawick 01/08/24 04:35:58 Modified:modules/mappers mod_negotiation.c Log: temporarily back out the buffering of .var files while folks have a chance to get APR ungetc working properly on buffered files Is this working on Win32 yet? --- mod_negotiation.c 2001/08/24 10:40:04 1.76 +++ mod_negotiation.c 2001/08/24 11:35:58 1.77 @@ -889,7 +889,7 @@ /* We are not using multiviews */ neg-count_multiviews_variants = 0; -if ((status = apr_file_open(map, rr-filename, APR_READ | APR_BUFFERED, +if ((status = apr_file_open(map, rr-filename, APR_READ /* | APR_BUFFERED */, -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: cvs commit: httpd-2.0/modules/mappers mod_negotiation.c
From: Jeff Trawick [EMAIL PROTECTED] Sent: Monday, August 27, 2001 3:42 PM [EMAIL PROTECTED] writes: trawick 01/08/24 04:35:58 Modified:modules/mappers mod_negotiation.c Log: temporarily back out the buffering of .var files while folks have a chance to get APR ungetc working properly on buffered files Is this working on Win32 yet? --- mod_negotiation.c 2001/08/24 10:40:04 1.76 +++ mod_negotiation.c 2001/08/24 11:35:58 1.77 @@ -889,7 +889,7 @@ /* We are not using multiviews */ neg-count_multiviews_variants = 0; -if ((status = apr_file_open(map, rr-filename, APR_READ | APR_BUFFERED, +if ((status = apr_file_open(map, rr-filename, APR_READ /* | APR_BUFFERED */, Probably not yet :( That is, buffering may work, but seek'ing within a buffered apr_file_t probably doesn't. Bill
[PATCH] default httpd.conf settings for worker MPM
As the worker MPM is really an alternative to the threaded MPM (and hopefully it'll be a replacement), the httpd.conf settings are identical. -aaron Index: highperformance-std.conf === RCS file: /home/cvspublic/httpd-2.0/docs/conf/highperformance-std.conf,v retrieving revision 1.5 diff -u -r1.5 highperformance-std.conf --- highperformance-std.conf2001/08/12 15:44:18 1.5 +++ highperformance-std.conf2001/08/27 20:49:20 @@ -34,6 +34,14 @@ ThreadsPerChild 25 /IfModule +IfModule worker.c +MaxClients 8 +StartServers 3 +MinSpareThreads 5 +MaxSpareThreads 10 +ThreadsPerChild 25 +/IfModule + # Assume no memory leaks at all MaxRequestsPerChild 0 Index: httpd-std.conf === RCS file: /home/cvspublic/httpd-2.0/docs/conf/httpd-std.conf,v retrieving revision 1.44 diff -u -r1.44 httpd-std.conf --- httpd-std.conf 2001/08/23 15:17:02 1.44 +++ httpd-std.conf 2001/08/27 20:49:20 @@ -130,6 +130,22 @@ MaxRequestsPerChild 0 /IfModule +# worker MPM +# StartServers: initial number of server processes to start +# MaxClients: maximum number of server processes allowed to start +# MinSpareThreads: minimum number of worker threads which are kept spare +# MaxSpareThreads: maximum number of worker threads which are kept spare +# ThreadsPerChild: constant number of worker threads in each server process +# MaxRequestsPerChild: maximum number of requests a server process serves +IfModule worker.c +StartServers 3 +MaxClients 8 +MinSpareThreads 5 +MaxSpareThreads 75 +ThreadsPerChild 25 +MaxRequestsPerChild 0 +/IfModule + # perchild MPM # NumServers: constant number of server processes # StartThreads: initial number of worker threads in each server process
Re: [PATCH] default httpd.conf settings for worker MPM
On Mon, Aug 27, 2001 at 01:52:48PM -0700, Aaron Bannert wrote: As the worker MPM is really an alternative to the threaded MPM (and hopefully it'll be a replacement), the httpd.conf settings are identical. Committed. Thanks. -- justin
Re: cvs commit: httpd-2.0/server core.c request.c
On Mon, Aug 27, 2001 at 09:47:28AM -0500, William A. Rowe, Jr. wrote:
if ((core_a-r != NULL) (core_b-r != NULL)) {
return -1;
}
else if ((core_a-r != NULL) (core_b-r != NULL)) {
return 1;
}
does that look better :-? I'll commit as soon as someone tells me sanity (or at
least
my abuse of pointers as bools) is cured :)
Ack, my C is getting too rusty. I seem to recall that (1 0) (0 1)
not portable. Perhaps the
if ((core_a-r == NULL) (core_b-r != NULL)) {
style reads better, I dunno.
Is it 100% certain that the component counts are always 0 (or some known
value) for regex sections? Haven't peeked at the source to check that.
If not, an additional else {...} defending the component count comparison
when in regex sections might be safer.
Oh, well, enough C golf for today ;-).
- Barrie
Re: location walk before directory walk
Just a question, but what if you are using .htaccess files to partition things up for virtual hosts? For example, I am running a server and both Roy and Bill have sites on it. Since I am a control freak, I refuse to give either access to httpd.conf, but because I am also lazy, I have allowed both to use .htaccess files. In that case, don't people need to be able to put localtion directives inside of .htaccess files? I would think that the appropriate thing to do in that situation is shoot the admin. [Or just tell them to use the config option that separates httpd.conf into a tree of separately owned directories.] Roy
Re: location walk before directory walk
On Monday 27 August 2001 14:23, Roy T. Fielding wrote: Just a question, but what if you are using .htaccess files to partition things up for virtual hosts? For example, I am running a server and both Roy and Bill have sites on it. Since I am a control freak, I refuse to give either access to httpd.conf, but because I am also lazy, I have allowed both to use .htaccess files. In that case, don't people need to be able to put localtion directives inside of .htaccess files? I would think that the appropriate thing to do in that situation is shoot the admin. [Or just tell them to use the config option that separates httpd.conf into a tree of separately owned directories.] I can accept that. Just asking a question to make sure we had thought everything through. :-) Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: cvs commit: httpd-2.0/server core.c request.c
Quick_handler bypasses everything. We ignore the client's headers, the server's configuration, everything. Frankly, quick_handler is not Apache, and anyone who writes a quick_handler hack and calls it a module for 'Apache' is full of sh*t. Powered by the Apr/Apache MPM/load manager is more like it (that isn't badness, that's just reality.) That's a goofy way of looking at it. You might as well say that Redirect is not Apache because it ignores Directory sections. And let's not even get into what can be done by mod_rewrite. A quick_handler operates the way that a Web server is supposed to operate. I should be able to add a hook that detects a Code Red request and immediately close the connection with as little server overhead as possible. Normally I would do that with a custom change to the HTTP parser, but it makes more sense to do it as a hook with quick_handler. It isn't a security hole -- it is just another config directive. Roy
Re: location walk before directory walk
From: Roy T. Fielding [EMAIL PROTECTED] Sent: Monday, August 27, 2001 4:23 PM Just a question, but what if you are using .htaccess files to partition things up for virtual hosts? For example, I am running a server and both Roy and Bill have sites on it. Since I am a control freak, I refuse to give either access to httpd.conf, but because I am also lazy, I have allowed both to use .htaccess files. In that case, don't people need to be able to put localtion directives inside of .htaccess files? I would think that the appropriate thing to do in that situation is shoot the admin. [Or just tell them to use the config option that separates httpd.conf into a tree of separately owned directories.] I still believe that there are fundemental per-vhost issues with eliminating the Location walk following whatever 'walkers' are configured by a given module/storage scheme. As a 'permission granted', there really is nothing wrong with using Location blocks. Restricting permissions with Location is futile, of course. Take this example DocumentRoot /userland/web/sites Directory /userland/web/sites Allow from all Deny from none /Directory Alias /DAVSpace/ /userland/web/sites/ Location /DAVSpace/ Dav On Order deny,allow Allow from localhost Require valid-user Satisfy Any /Location This configuration would be impossible without the trailing Location config. Note we don't walk that config any more. Since the request for /DAVSpace/myfile was satisfied on the first try, the URI didn't change during the directory walk, the premerged location will be reused. That's the benefit of my patch last night. Bill
Re: cvs commit: httpd-2.0/server core.c request.c
From: Roy T. Fielding [EMAIL PROTECTED] Sent: Monday, August 27, 2001 4:45 PM A quick_handler operates the way that a Web server is supposed to operate. I should be able to add a hook that detects a Code Red request and immediately close the connection with as little server overhead as possible. Normally I would do that with a custom change to the HTTP parser, but it makes more sense to do it as a hook with quick_handler. I'd really like to see a quick_handler patch that has the socket drop that connection entirely, waiting in SYN for the ACK response :) Bill
Re: Fw: HTTP response problem on 2.0.24
William A. Rowe, Jr. wrote: This is the reason that the huge number of folks offering their 'binaries' irks me. Here's the problem: On *nix machines you can get a compiler for free and figure out how to use it. If you can figure out how to use it, then you're probably smart enough to know what you're getting into by building an alpha quality product. With the Windows platform the compiler costs a minimum of $100+. That is out of the range for many qualified persons to afford (I couldn't even afford it now). It is also out of the range of persons who primarily run *nix but do some testing on Windows. That is the reason for my binaries. It is not to let anyone and everyone download Apache. If I knew of a way to stop unqualified individuals from downloading it I would do it. Do you know any way? PS - Sorry for the OT spam, but I could not find these posts on my NNTP server. -- Jerry Baker PGP Key: http://www.jerrybaker.org/pgp.html LAME MP3 Encoder Binaries: http://www.jerrybaker.org/lame/ Apache 2.0 Web server Installer: http://www.jerrybaker.org/apache/
Re: chunking of content in mod_include?
On Monday 27 August 2001 16:05, Brian Pane wrote: In mod_include's find_start_sequence function, there's some code that splits the current bucket if ctx-bytes_parsed = BYTE_COUNT_THRESHOLD. Can somebody explain the rationale for this? It seems redundant to be splitting the data into smaller chunks in a content filter; I'd expect mod_include to defer network block sizing to downstream filters. In the profile data I'm looking at currently, this check accounts for 35% of the total run time of find_start_sequence, so there's some performance to be gained if the ctx-bytes_parsed = BYTE_COUNT_THRESHOLD check can be eliminated. It is used to ensure that we don't buffer all the data in mod_include. It isn't really done correctly though, because what we should be doing, is just continuing to read as much data as possible, but as soon as we can't read something, send what we have down the filter stack. This variable, basically ensures we don't keep reading all the data until we process the whole file, or reach the first tag. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Fw: HTTP response problem on 2.0.24
Just to file this away where I won't loose it. Unfortuatnely, with buckets, it will be a danged site difficult to find the win9x invalid operation. Sort of cute that we bubble up rv's instead of http result codes :( Bill - Original Message - From: William A. Rowe, Jr. [EMAIL PROTECTED] Newsgroups: comp.infosystems.www.servers.ms-windows Sent: Monday, August 27, 2001 4:00 PM Subject: Re: HTTP response problem on 2.0.24 It's a network error (32045 - 22000 is 10045, winsock error WSAEOPNOTSUPP). Now that's odd. But as everything on the ASF site indicates, it really doesn't work on Windows 9x (or ME) yet. You were warned. This is the reason that the huge number of folks offering their 'binaries' irks me. Please don't any support on this yet. A beta for Windows NT is in the works (likely to be 2.0.25) and a beta on 9x will follow the next month. But as the group has always indicated, if you can't compile Apache yourself, you aren't ready for 2.0 (or, 2.0 isn't ready for you :) Bill Michael Maclean [EMAIL PROTECTED] wrote in message news:9mebgr$1e261$[EMAIL PROTECTED]... Hi, Apologies if this is a blindingly obvious problem ;o) I downloaded the Windows binary of Apache 2.0.24 from Jerry Baker's site and installed it onto my 98 First Edition machine, and all seems to be fine. I changed all the @@ lines in httpd.conf to valid values and started the server, and it seemed to work fine. I then changed it to run on port 8080 to avoid messing with my existing 1.3.20 setup. I then started running through the manual pages in the htdocs folder via http://localhost:8080, until I tries to access the /manual/misc/FAQ.html page. When I did this, it came back with a page titled 200 OK and saying OK then The server encountered an internal error or misconfiguration... like you get with a 500 error. It only seems to happen with certain pages: /manual/misc/client_block_api.html seems to work fine. Nothing appears in the error log when this happens, but the access log looks like this: 127.0.0.1 - - [27/Aug/2001:21:44:35 +] GET /manual/misc/FAQ.html HTTP/1.1 32045 119496 indicating a 32045 HTTP response code. Anyone have any ideas? -- Cheers, Michael
[PATCH] worker MPM: reuse transaction pools
This patch implements a resource pool of context pools -- a queue of
available pools that the listener thread can pull from when accepting
a request. The worker thread that picks up that request then uses
that pool for the lifetime of that transaction, clear()ing the pool
and releasing it back to what I'm calling the pool_queue (har har).
This replaces the prior implementation that would create and destroy
a transaction pool for each and every request.
I'm seeing a small performance improvement with this patch, but I suspect
the fd_queue code could be improved for better parallelism. I also
suspect that with better testing this algorithm may prove more scalable.
-aaron
Index: worker.c
===
RCS file: /home/cvspublic/httpd-2.0/server/mpm/worker/worker.c,v
retrieving revision 1.17
diff -u -r1.17 worker.c
--- worker.c2001/08/26 01:24:41 1.17
+++ worker.c2001/08/28 00:00:03
@@ -125,6 +125,7 @@
static int num_listensocks = 0;
static apr_socket_t **listensocks;
static fd_queue_t *worker_queue;
+static fd_queue_t *pool_queue; /* a resource pool of context pools */
/* The structure used to pass unique initialization info to each thread */
typedef struct {
@@ -203,6 +204,7 @@
/* XXX: This will happen naturally on a graceful, and we don't care otherwise.
ap_queue_signal_all_wakeup(worker_queue); */
ap_queue_interrupt_all(worker_queue);
+ap_queue_interrupt_all(pool_queue);
}
AP_DECLARE(apr_status_t) ap_mpm_query(int query_code, int *result)
@@ -556,6 +558,7 @@
int thread_slot = ti-tid;
apr_pool_t *tpool = apr_thread_pool_get(thd);
apr_socket_t *csd = NULL;
+apr_socket_t *dummycsd = NULL;
apr_pool_t *ptrans;/* Pool for per-transaction stuff */
apr_socket_t *sd = NULL;
int n;
@@ -641,9 +644,20 @@
}
got_fd:
if (!workers_may_exit) {
-/* create a new transaction pool for each accepted socket */
-apr_pool_create(ptrans, tpool);
+/* pull the next available transaction pool from the queue */
+if ((rv = ap_queue_pop(pool_queue, dummycsd, ptrans))
+!= FD_QUEUE_SUCCESS) {
+if (rv == FD_QUEUE_EINTR) {
+goto got_fd;
+}
+else { /* got some error in the queue */
+csd = NULL;
+ap_log_error(APLOG_MARK, APLOG_ERR, rv, ap_server_conf,
+ap_queue_pop);
+}
+}
+
if ((rv = apr_accept(csd, sd, ptrans)) != APR_SUCCESS) {
csd = NULL;
ap_log_error(APLOG_MARK, APLOG_ERR, rv, ap_server_conf,
@@ -678,9 +692,7 @@
ap_scoreboard_image-parent[process_slot].quiescing = 1;
kill(ap_my_pid, SIGTERM);
-/* this is uncommented when we make a pool-pool
apr_thread_exit(thd, APR_SUCCESS);
-*/
return NULL;
}
@@ -695,8 +707,6 @@
free(ti);
-/* apr_pool_create(ptrans, tpool); */
-
while (!workers_may_exit) {
rv = ap_queue_pop(worker_queue, csd, ptrans);
/* We get FD_QUEUE_EINTR whenever ap_queue_pop() has been interrupted
@@ -708,11 +718,16 @@
}
process_socket(ptrans, csd, process_slot, thread_slot);
requests_this_child--; /* FIXME: should be synchronized - aaron */
-apr_pool_destroy(ptrans);
+
+/* get this transaction pool ready for the next request */
+apr_pool_clear(ptrans);
+/* don't bother checking if we were interrupted in ap_queue_push,
+ * because we're going to check workers_may_exit right now anyway. */
+ap_queue_push(pool_queue, NULL, ptrans);
}
-ap_update_child_status(process_slot, thread_slot, (dying) ? SERVER_DEAD :
SERVER_GRACEFUL,
-(request_rec *) NULL);
+ap_update_child_status(process_slot, thread_slot,
+(dying) ? SERVER_DEAD : SERVER_GRACEFUL, (request_rec *) NULL);
apr_lock_acquire(worker_thread_count_mutex);
worker_thread_count--;
apr_lock_release(worker_thread_count_mutex);
@@ -731,7 +746,7 @@
return 0;
}
-static void *start_threads(apr_thread_t *thd, void * dummy)
+static void *start_threads(apr_thread_t *thd, void *dummy)
{
thread_starter *ts = dummy;
apr_thread_t **threads = ts-threads;
@@ -743,12 +758,24 @@
int i = 0;
int threads_created = 0;
apr_thread_t *listener;
+apr_pool_t *ptrans;
+apr_socket_t *dummycsd = NULL;
-/* We must create the fd queue before we start up the listener
+/* We must create the fd queues before we start up the listener
* and worker threads. */
-worker_queue = apr_pcalloc(pchild, sizeof(*worker_queue));
+worker_queue = apr_pcalloc(pchild, sizeof(fd_queue_t));
ap_queue_init(worker_queue, ap_threads_per_child, pchild);
+/* create the resource pool of available transaction pools */
+pool_queue =
Re: [PATCH] add authenticated user details to environment
On Mon, 2001-08-27 at 17:09, Graham Leggett wrote: Hi all, hi. just wondering if you wanted to set the 'main' subprocess table instead of a child when 'auth_ldap' gets called for a subrequest. currently you are only setting the subrequests subprocess table. This patch allows user data belonging to a basic-authenticated user to be added to the environment for the benefit of mod_include. This makes it possible to embed user details in a page like so: Hello !--#echo var=AUTHENTICATE_CN--, your telephone number is !--#echo var=AUTHENTICATE_TELEPHONENUMBER--. This first patch is for mod_ldap and mod_auth_ldap, I intend making similar functionality for the other auth modules. Regards, Graham -- Ian Holsman Performance Measurement Analysis CNET Networks-415 364-8608
Re: chunking of content in mod_include?
Paul J. Reder wrote: Ryan Bloom wrote: On Monday 27 August 2001 16:05, Brian Pane wrote: In mod_include's find_start_sequence function, there's some code that splits the current bucket if ctx-bytes_parsed = BYTE_COUNT_THRESHOLD. Can somebody explain the rationale for this? It seems redundant to be splitting the data into smaller chunks in a content filter; I'd expect mod_include to defer network block sizing to downstream filters. In the profile data I'm looking at currently, this check accounts for 35% of the total run time of find_start_sequence, so there's some performance to be gained if the ctx-bytes_parsed = BYTE_COUNT_THRESHOLD check can be eliminated. It is used to ensure that we don't buffer all the data in mod_include. It isn't really done correctly though, because what we should be doing, is just continuing to read as much data as possible, but as soon as we can't read something, send what we have down the filter stack. This variable, basically ensures we don't keep reading all the data until we process the whole file, or reach the first tag. In what manner do you mean as soon as we can't read something? It is my understanding that the bucket code hides reading delays from the mod_include code. If that is true how would the mod_include code know when to send a chunk along? Are you saying the bucket code should do some magic like send all buckets in the brigade up to the current one? This would wreak havoc on code like mod_include that may be setting aside or tagging buckets for replacement when the end of the tag is found. This code was put in because we were seeing the mod_include code buffer up the entire collection of buckets until an SSI tag was found. If you have a 200 MB file with an SSI tag footer at the end of the brigade, the whole thing was being buffered. How do you propose that this be done differently? The only thing I can think of is to add to and check the byte tally at bucket boundaries. We might go over the BYTE_COUNT_THRESHOLD, but the check wouldn't happen on every byte and there wouldn't need to be a bucket split to send along the first part. Is this what you mean? I think checking on bucket boundaries would be better. And to guard against the case where a single bucket might contain 200 MB of data, wouldn't it work to just check the bucket size right after the apr_bucket_read in find_start_sequence and split the bucket there if its size exceeds some reasonable threshold? --Brian
Re: chunking of content in mod_include?
On Mon, 27 Aug 2001, Brian Pane wrote: The only thing I can think of is to add to and check the byte tally at bucket boundaries. We might go over the BYTE_COUNT_THRESHOLD, but the check wouldn't happen on every byte and there wouldn't need to be a bucket split to send along the first part. Is this what you mean? I think checking on bucket boundaries would be better. And to guard against the case where a single bucket might contain 200 MB of data, wouldn't it work to just check the bucket size right after the apr_bucket_read in find_start_sequence and split the bucket there if its size exceeds some reasonable threshold? Let me second that idea... checking per-bucket would be WAY better IMO. --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: chunking of content in mod_include?
On Monday 27 August 2001 19:25, Paul J. Reder wrote: Ryan Bloom wrote: On Monday 27 August 2001 16:05, Brian Pane wrote: In mod_include's find_start_sequence function, there's some code that splits the current bucket if ctx-bytes_parsed = BYTE_COUNT_THRESHOLD. Can somebody explain the rationale for this? It seems redundant to be splitting the data into smaller chunks in a content filter; I'd expect mod_include to defer network block sizing to downstream filters. In the profile data I'm looking at currently, this check accounts for 35% of the total run time of find_start_sequence, so there's some performance to be gained if the ctx-bytes_parsed = BYTE_COUNT_THRESHOLD check can be eliminated. It is used to ensure that we don't buffer all the data in mod_include. It isn't really done correctly though, because what we should be doing, is just continuing to read as much data as possible, but as soon as we can't read something, send what we have down the filter stack. This variable, basically ensures we don't keep reading all the data until we process the whole file, or reach the first tag. In what manner do you mean as soon as we can't read something? It is my understanding that the bucket code hides reading delays from the mod_include code. If that is true how would the mod_include code know when The bucket does not hide reading delays at all. Basically, you call apr_bucket_read with APR_NONBLOCK_READ, and when you get a return code of APR_EAGAIN, you send what you have, and then call apr_bucket_read with APR_BLOCK_READ. to send a chunk along? Are you saying the bucket code should do some magic like send all buckets in the brigade up to the current one? This would wreak havoc on code like mod_include that may be setting aside or tagging buckets for replacement when the end of the tag is found. Huh? The bucket code doesn't ever send data down the filter stack unless you tell it to. Take a look at the content-length filter to see what I mean. This code was put in because we were seeing the mod_include code buffer up the entire collection of buckets until an SSI tag was found. If you have a 200 MB file with an SSI tag footer at the end of the brigade, the whole thing was being buffered. How do you propose that this be done differently? I don't care if mod_include buffers 200 Megs, as long as it is constantly doing something with the data. If we have a 200 Meg file that has no SSI tags in it, but we can get all 200 Meg at one time, then we shouldn't have any problem just scanning through the entire 200 Megs very quickly. Worst case, we do what Brian suggested, and just check the bucket length once we have finished processing all of the data in that bucket. The buffering only becomes a real problem when we sit waiting for data from a CGI or some other slow content generator. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: mod_tls
On Thu, 23 Aug 2001, Ryan Bloom wrote: Because mod_ssl only implements the SSL wrapping for HTTP. The idea is that the filters go in mod_tls, and mod_ssl just has the logic to make the filters work for HTTP. That way, SSL can work with POP3, NNTP, and the proxy. i think mod_ssl should work with all protocols (it works with nntp right now). mod_ssl provides features such as: CRLs session caching per-location renegotation SSLRequire logging var lookups and so on that are not http specific. there is a bit more effort to get a protocol module such as nntp working both with and without ssl. for example with nntp when the first client connects it does not send a request (like http clients do), but awaits a 200 - ready response. to work with ssl, an nntp protocol module needs to first call get_brigade to trigger the initial ssl negotiation. but the same issue is there with mod_tls. personally, i don't think its worth the effort to maintain both mod_tls and mod_ssl. effort would be better spent modularizing mod_ssl to support other protocols if needed.
