Re: zlib inclusion and mod_gz(ip) recap
Greg Stein wrote... Kevin Kiley asked... What's it going to take to find out once and for all if ZLIB can be included in the Apache source tree? It won't go in. No need for it. That hasn't been well-stated... It has now, it seems ( finally! ). Only takes one veto and looks like between you ( and/or Ryan ) there will never be any ZLIB sources in Apache. End of story. Good to know. As stated elsewhere, pcre and expat are in there because they aren't typically available, like zlib is. Ah... so that's the criteria? Ok. I believe the other libs you mention have been 'tweaked' and that's another reason why the source is there, yes? What if you ever need to 'tweak' ZLIB because it was never really designed to be a real-time data compression engine? Would that remove the 'no ZLIB source' dictum? Nothing needs to happen, so it shouldn't be surprising :-). If/when we need it, then we will include it. As I said, it is just config macros. You are putting an awful lot of faith in ZLIB and the assumption that it will suit your needs 'out of the box' but I hear ya... There are three options on the table: 1) include mod_gzip 2) include mod_gz 3) include neither I believe there is consensus that (3) is not an option. Huh? I didn't see any real consensus on that. Only a real vote will tell you that. Why note call for one?... not a vote on any particular piece of code but whether or not to include anything to do with IETF Content-Encoding into the actual CORE or standard module base ( for now ). That will tell the story about option 3 for sure. Ryan himself said he prefers 3 right off the bat when Jerry said 'Let's dump Ian's mod_gz into the core!' which is what started this whole entire thread. His (Ryan's) preference is that for the time being ( and I'm beginning to lean that way myself in light of this discussion ) is just leave the IETF Content-Encoding stuff out of the core and let 3rd party modules handle it. That'll work. That's the way it works right now and thousands of real Apache users don't seem to have a problem with that. No one ( including myself ) has made any kind of airtight case yet as to WHY IETF Content-Encoding support SHOULD be in the core Server itself. I am not sure I could, at this point, after seeing that anyone who really wants to compress responses knows how to locate and install a module that will do so ( mod_gzip ). I guess it would be easier for folks to 'get' it in the tarball but that hasn't stopped a few thousand people finding/using mod_gzip over the last year or so even I have to admit putting it all in the core doesn't seem like a house on fire. Despite yours and Peters pushing and stressing and overbearing sell job to get mod_gz(ip) type functionality into the core, it was just preaching to the choir. (well, okay: maybe Ryan didn't want to see it in there :-) That sell job mostly served to create an air of hostility. Yea... okay... whatever... we are the 'bad guys' again for trying to improve your Server. Mea Culpa. So now the question comes down to using (1) or (2). People are *not* voting on including mod_gz because they want to see your alternative. I think it is pretty much that simple. Yea... I guess. But then you say to look at the 1.3 version. What I meant was... if anyone wants to see right away if a whole bunch of pure 'coding style' bullshit is going to be the show stopper right off the bat then there's no need to wait for anything. As I have said 3 times now... it doesn't take rocket scientist to look at an existing module and imagine what it will STILL look like with filtering calls in it. I assure you... I did not rewrite the 1.3.x module just for 2.0. All I did was add the filtering calls. It was no big deal. Ian himself could have probably done the same in less time than it took him to write the mod_gz demo in the first place. I also haven't gotten an answer to my question regarding the weird comment that appeared in this discussion about any module being submitted that supports both 1.3.x AND 2.0 in the same code ( which the mod_gzip I have here certainly does ) will be rejected for that reason alone. Is that true? If so... then this is all a moot point. I don't have the time at the moment to hack up a perfectly fine module that supports ALL versions of Apache into something that ONLY cares about Apache 2.0. I am not even sure I would... it seems like a really stupid thing to do. Whether the changes are large or small, they'd rather see your current work because we already know the port has been completed and *tested*. We'd have to redo all of that work, which just seems silly. Yep... sure would be. So the inclusion of either is blocked on seeing the source to mod_gzip for Apache 2.0. Not really... The vote about mod_gz was still in progress. It was about to 'pass', I think. Why not start it over again and see if it actually does? Maybe a legal
[PATCH] Potential replacement for find_start_sequence...
I'm not totally sure I'm sold on this approach being better. But,
I'm not sure that it is any worse either. Don't have time to
benchmark this right now. I'm going to throw it to the wolves and
see what you think.
Basically, replace the inner search with a Rabin-Karp search (which
seemed to best describe whatever OtherBill posted - I read what you
posted and then I looked through my books and this seems to be the
closest one to whatever you were describing - it uses a hash value
- it's probably not even close to what you had in mind).
This patch also handles the leftover case independently (why there
is a new function as a portion of the code gets called twice). (Too
bad we don't have a super-bucket that would allow a portion of a
bucket to get added to another bucket. If this were there, a lot of
code could be simplified throughout the server, I think...)
You could, in theory, replace it with a KMP search (the search
algorithm doesn't matter too much in this patch). I think
Rabin-Karp gets you linear time. But, I think we already had
that. However, the inner loop gets dramatically reduced (two
mathematical formulas versus 3 ifs that may have been nullifying
branch predicition).
I'm wondering where we are spending our time in find_start_sequence.
BTW, I know this works in the limited testing I gave it. -- justin
Index: modules/filters/mod_include.c
===
RCS file: /home/cvs/httpd-2.0/modules/filters/mod_include.c,v
retrieving revision 1.143
diff -u -r1.143 mod_include.c
--- modules/filters/mod_include.c 2001/09/04 02:13:58 1.143
+++ modules/filters/mod_include.c 2001/09/05 08:23:31
@@ -206,6 +206,54 @@
/* --- Parser functions --- */
+/* Rabin-Karp search as described in Sedgewick 2nd Ed, */
+int rksearch(const char *p, int pLen, const char *a, int aLen)
+{
+const int q = 33554393;
+const int d = 32;
+int i, dM = 1, h1 = 0, h2 = 0;
+int M = pLen, N = aLen;
+for (i = 1; i M; i++) dM = (d*dM) % q;
+for (i = 0; i M; i++) {
+h1 = (h1*d+p[i]) % q;
+h2 = (h2*d+a[i]) % q;
+}
+for (i = 0; h1 != h2; i++) {
+h2 = (h2+d*q-a[i]*dM) % q;
+h2 = (h2*d+a[i+M]) % q;
+if (i N - M) return N;
+}
+return i;
+}
+
+/* We've now found a start sequence tag... */
+static apr_bucket* found_start_sequence(apr_bucket *dptr,
+ include_ctx_t *ctx,
+ int tagStart)
+{
+/* We want to split the bucket at the ''. */
+ctx-state = PARSE_DIRECTIVE;
+ctx-tag_length = 0;
+ctx-parse_pos = 0;
+ctx-tag_start_bucket = dptr;
+ctx-tag_start_index = tagStart;
+if (ctx-head_start_index 0) {
+apr_bucket *tmp_bkt;
+
+/* Split the bucket with the start of the tag in it */
+apr_bucket_split(ctx-head_start_bucket, ctx-head_start_index);
+tmp_bkt = APR_BUCKET_NEXT(ctx-head_start_bucket);
+/* If it was a one bucket match */
+if (dptr == ctx-head_start_bucket) {
+ctx-tag_start_bucket = tmp_bkt;
+ctx-tag_start_index = tagStart - ctx-head_start_index;
+}
+ctx-head_start_bucket = tmp_bkt;
+ctx-head_start_index = 0;
+}
+return ctx-head_start_bucket;
+}
+
/* This function returns either a pointer to the split bucket containing the
* first byte of the BEGINNING_SEQUENCE (after finding a complete match) or it
* returns NULL if no match found.
@@ -217,8 +265,8 @@
const char *c;
const char *buf;
const char *str = STARTING_SEQUENCE;
-apr_bucket *tmp_bkt;
-apr_size_t start_index;
+int slen = strlen(str);
+int pos;
*do_cleanup = 0;
@@ -269,8 +317,53 @@
if (len == 0) { /* end of pipe? */
break;
}
+
+/* Set our buffer to use. */
+
c = buf;
-while (c buf + len) {
+/* The last bucket had a left over partial match that we need to
+ * complete.
+ */
+if (ctx-state == PARSE_HEAD)
+{
+apr_size_t tmpLen;
+tmpLen = (len (slen - 1)) ? len : (slen - 1);
+
+while (c buf + tmpLen *c == str[ctx-parse_pos])
+{
+c++;
+ctx-parse_pos++;
+}
+
+if (str[ctx-parse_pos] == '\0')
+{
+ctx-bytes_parsed += c - buf;
+return found_start_sequence(dptr, ctx, c - buf);
+}
+
+/* False alarm... */
+ctx-state = PRE_HEAD;
+}
+
+if (len)
+{
+pos = rksearch(str, slen, c, len);
+if (pos != len)
+{
+ctx-head_start_bucket = dptr;
+ctx-head_start_index = pos;
+ctx-bytes_parsed += pos + slen;
+return
mod_include.c WAS: RE: remaining CPU bottlenecks in 2.0
* find_start_sequence() is the main scanning function within mod_include. There's some research in progress to try to speed this up significantly. Based on the patches you submitted (and my quasi-errant formatting patch), I had to read most of the code in mod_include, so I'm more familiar with mod_include now. I do think there are some obvious ways to optimize find_start_sequence. I wonder if we could apply a KMP-string matching algorithm here. I dunno. I'll take a look at it though. Something bugs me about the restarts. I bet that we spend even more time in find_start_sequence when a HTML file has lots of comments. =-) I suggested to Ian yesterday night that I'd look into a Boyer-Moore matching algorithm. I'll work on that too. Sander
RE: [PATCH] Potential replacement for find_start_sequence...
I'm not totally sure I'm sold on this approach being better. But, I'm not sure that it is any worse either. Don't have time to benchmark this right now. I'm going to throw it to the wolves and see what you think. Me neither. Rabin-Karp introduces a lot of * and %. I'll try Boyer-Moore with precalced tables for '!--#' and '---'. [...] Sander
sub requests are all GETs
Can anybody explain why ap_set_sub_req_protocol does rnew-method = GET; rnew-method_number = M_GET; instead of rnew-method = r-method; rnew-method_number = r-method_number; ? The consequence is that functions like negotiation sub_req = ap_sub_req_lookup_file(dirent.name, r, NULL); check auth on the wrong method. You can check this by POSTing to foo and having a limit on POST for foo.php3 (as opposed to the whole directory). A quick way to check is to set a breakpoint in ap_set_sub_req_protocol and telnet localhost 80 POST /Overview HTTP/1.0 Content-Length: 5 abcd Any calls to the auth modules will have a method of GET despite the POST action they will eventually execute. All auth modules and the like could check for this: int method = r-main ? r-main-method_number : r-method_number; but it seems better to have the sub request default to the method of the request that inspired it. There may be some modules that may count on the default behavior, like mod_include, but I think they should specifically make the new method be a GET as they are not duplicating the parent request's behaviour. -- -eric ([EMAIL PROTECTED]) Feel free to forward this message to any list for any purpose other than email address distribution.
Re: cvs commit: apache-1.3/src/modules/standard mod_rewrite.h
[EMAIL PROTECTED] writes: jim 01/09/04 11:15:16 Modified:src CHANGES PORTING src/include ap_config.h http_main.h src/lib/sdbm sdbm_lock.c src/main http_core.c http_main.c src/modules/standard mod_rewrite.h Log: Add the AcceptMutex runtime directive, which allows for the accept mutexing method to be set at runtime (the suite of methods is set at compile time still). I don't like the feature of selecting a default mechanism if the AcceptMutex foo directive is invalid. I think the admin should get the same feedback she'd get if she miscoded anything else. I'm not accustomed to Apache continuing to initialize if a directive is miscoded. -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: sub requests are all GETs
Take a look at ap_sub_req_method_uri. That might do the trick for you. I don't think there is a similar one for files right now. Cheers, -g On Wed, Sep 05, 2001 at 08:17:15AM -0400, Eric Prud'hommeaux wrote: Can anybody explain why ap_set_sub_req_protocol does rnew-method = GET; rnew-method_number = M_GET; instead of rnew-method = r-method; rnew-method_number = r-method_number; ? The consequence is that functions like negotiation sub_req = ap_sub_req_lookup_file(dirent.name, r, NULL); check auth on the wrong method. You can check this by POSTing to foo and having a limit on POST for foo.php3 (as opposed to the whole directory). A quick way to check is to set a breakpoint in ap_set_sub_req_protocol and telnet localhost 80 POST /Overview HTTP/1.0 Content-Length: 5 abcd Any calls to the auth modules will have a method of GET despite the POST action they will eventually execute. All auth modules and the like could check for this: int method = r-main ? r-main-method_number : r-method_number; but it seems better to have the sub request default to the method of the request that inspired it. There may be some modules that may count on the default behavior, like mod_include, but I think they should specifically make the new method be a GET as they are not duplicating the parent request's behaviour. -- -eric ([EMAIL PROTECTED]) Feel free to forward this message to any list for any purpose other than email address distribution. -- Greg Stein, http://www.lyra.org/
Re: cvs commit: apache-1.3/src/modules/standard mod_rewrite.h
I don't like the feature of selecting a default mechanism if the AcceptMutex foo directive is invalid. I think the admin should get the same feedback she'd get if she miscoded anything else. I'm not accustomed to Apache continuing to initialize if a directive is miscoded. Yea, I think I agree. Easy to change... The switch to default *is* logged, however... -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither
Re: zlib inclusion and mod_gz(ip) recap
On Wed, Sep 05, 2001 at 03:56:32AM -0400, [EMAIL PROTECTED] wrote: Greg Stein wrote... ... As stated elsewhere, pcre and expat are in there because they aren't typically available, like zlib is. Ah... so that's the criteria? Ok. Generally, yes. But size matters :-) OpenSSL 0.9.6 isn't commonly installed, but it is too big for us to include. (not to mention the general crypto issues) I believe the other libs you mention have been 'tweaked' and that's another reason why the source is there, yes? We try to avoid it. Speaking for Expat, any differnces from Expat's CVS is simply because I haven't done the cross-patching needed yet. What if you ever need to 'tweak' ZLIB because it was never really designed to be a real-time data compression engine? Would that remove the 'no ZLIB source' dictum? It certainly could, yes. Nothing needs to happen, so it shouldn't be surprising :-). If/when we need it, then we will include it. As I said, it is just config macros. You are putting an awful lot of faith in ZLIB and the assumption that it will suit your needs 'out of the box' but I hear ya... Until I learn differently, I'll trust that all the other zillions of zlib users have ironed out the problems. At this point, I have no concrete evidence that problems exist in zlib; just some FUD :-) There are three options on the table: 1) include mod_gzip 2) include mod_gz 3) include neither I believe there is consensus that (3) is not an option. Huh? I didn't see any real consensus on that. Only a real vote will tell you that. We don't always need votes to get a general feeling of people's thoughts on various issues. Why note call for one?... not a vote on any particular piece of code Because we don't need to. General consensus is supportive. We'll continue on the assumption that *something* will go in, until somebody actually gets up and vetoes it. But that probably wouldn't happen until we've selected mod_gz or mod_gzip for what goes into Apache. ... Ryan himself said he prefers 3 right off the bat when Jerry said 'Let's dump Ian's mod_gz into the core!' which is what started this whole entire thread. Ask him what he thinks now :-) Knowing Ryan, he is probably fine with adding it at this point. ... No one ( including myself ) has made any kind of airtight case There is very little that goes into Apache nowadays that has an airtight case. A general feeling of consensus implies we don't need it. ... Despite yours and Peters pushing and stressing and overbearing sell job to get mod_gz(ip) type functionality into the core, it was just preaching to the choir. (well, okay: maybe Ryan didn't want to see it in there :-) That sell job mostly served to create an air of hostility. Yea... okay... whatever... we are the 'bad guys' again for trying to improve your Server. Mea Culpa. Now you're just misconstruing what I said. I talked about your *approach*. Your intent/hope to improve Apache is welcome and appreciated. But you consistently aggravate people with how you approach and handle discussions. ... But then you say to look at the 1.3 version. What I meant was... if anyone wants to see right away if a whole bunch of pure 'coding style' bullshit is going to be the show stopper right off the Coding style is never a showstopper. When it goes it, we will make it fit the Apache coding style. Just ask Ben Laurie what some of his contributions look like now :-) Yes, people have complained about stuff in mod_gzip 1.x, but don't misinterpret that as a flat out veto. bat then there's no need to wait for anything. As I have said 3 times now... it doesn't take rocket scientist to look at an existing module and imagine what it will STILL look like with filtering calls in it. Of course. But people want to see mod_gzip 2.0, not the old one. I assure you... I did not rewrite the 1.3.x module just for 2.0. All I did was add the filtering calls. It was no big deal. The post the fucker already. Just what is your problem with posting it? If you want us to integrate it, then why not post it NOW? Please explain. ... I also haven't gotten an answer to my question regarding the weird comment that appeared in this discussion about any module being submitted that supports both 1.3.x AND 2.0 in the same code ( which the mod_gzip I have here certainly does ) will be rejected for that reason alone. As with the coding style, you are conflating acceptance of a module with things that people will want to see changed. Just because people want changes to be made doesn't mean they are flat out reject the *entire* module. When it goes into source control, people will: * adjust the coding style to match Apache * possibly strip unnecessary debug stuff * strip out Apache 1.3 support since the code resides in the 2.0 repository ... If so... then this is all a moot point. I don't have the time at the moment to hack up a perfectly fine module that
Re: remaining CPU bottlenecks in 2.0
On Tue, Sep 04, 2001 at 11:56:48PM -0500, William A. Rowe, Jr. wrote: ... You were discussing the possibility of parsing for !--# as a skip by 5. Consider jumping to a 4 byte alignment, truncating to char and skip by dwords. E.g., you only have to test for three values, not four, and you can use the machine's most optimal path. But I'd ask if strstr() isn't optimized on the platform, why are we reinventing it? strstr() can't find strings that span a bucket boundary. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: Fw: Regarding lower-case HTML tags
At 11:12 PM 09/04/2001, William A. Rowe, Jr. wrote: I've been using tidy, from the w3c, for a while now, to do pretty-reformatting of HTML documents. One of the things that it does is lower-case HTML tags. I was wondering, in light of comments made a week or two ago, whether it would be worthwhile to do this with files in the docs as I a working with them? The reason it does that is that XML is case-sensitive for tag names, and the HTML working group chose to use lowercase for XHTML. Thus, if the pages were ever to be marked as XHTML, they'd need to be lowercase. -- Greg Marr [EMAIL PROTECTED] We thought you were dead. I was, but I'm better now. - Sheridan, The Summoning
Re: sub requests are all GETs
On Wed, Sep 05, 2001 at 05:46:15AM -0700, Greg Stein wrote:
Take a look at ap_sub_req_method_uri. That might do the trick for you.
I don't think there is a similar one for files right now.
Thanks. I took a look at ap_sub_req_method_uri and am still whining:
ap_sub_req_method_uri takes a method string argument and returns a sub
req with that method. All functions that could be creating POST, PUT,
etc requests should perhaps use it like this:
rnew = ap_sub_req_method_uri(r-method, newUri, r, somefilter)
but they don't. They all call ap_sub_req_lookup_uri wich hard codes it:
return ap_sub_req_method_uri(GET, new_file, r, next_filter);
I haven't tested, but it seems like a number of the callers of
ap_sub_req_lookup_uri may be subject to the problem I'm addressing
in ap_sub_req_lookup_file.
The problem I'm trying to solve here is to make the ACLs on negotiated
files work out of the box. As it is, if the ACL is only on foo.php3, a
POST to foo will cause, for instance, mod_auth's check_user_access to
check the ACLs for POST on foo and later, after mod_negotiation does
its trick, check the ACLs for GET on foo.php3. If Joe user is allowed
to GET foo.php3 he can sneak around the ACLs by POSTing to foo.
I saw this problem back in 1.3 and figured I'd tackle it if it was
still around in 2.0. I think the solution proposed below will work
but I haven't checked mod_{dav,include,autoindex} to see that they
don't mean to create a sub req that truly is a GET and not whatever
the parent req was.
On Wed, Sep 05, 2001 at 08:17:15AM -0400, Eric Prud'hommeaux wrote:
Can anybody explain why ap_set_sub_req_protocol does
rnew-method = GET;
rnew-method_number = M_GET;
instead of
rnew-method = r-method;
rnew-method_number = r-method_number;
? The consequence is that functions like negotiation
sub_req = ap_sub_req_lookup_file(dirent.name, r, NULL);
check auth on the wrong method. You can check this by POSTing to
foo and having a limit on POST for foo.php3 (as opposed to the
whole directory). A quick way to check is to set a breakpoint in
ap_set_sub_req_protocol and
telnet localhost 80
POST /Overview HTTP/1.0
Content-Length: 5
abcd
Any calls to the auth modules will have a method of GET despite
the POST action they will eventually execute.
All auth modules and the like could check for this:
int method = r-main ? r-main-method_number : r-method_number;
but it seems better to have the sub request default to the method
of the request that inspired it. There may be some modules that
may count on the default behavior, like mod_include, but I think
they should specifically make the new method be a GET as they are
not duplicating the parent request's behaviour.
--
-eric
([EMAIL PROTECTED])
Feel free to forward this message to any list for any purpose other than
email address distribution.
--
Greg Stein, http://www.lyra.org/
--
-eric
([EMAIL PROTECTED])
Feel free to forward this message to any list for any purpose other than
email address distribution.
Re: zlib inclusion and mod_gz(ip) recap
Ryan himself said he prefers 3 right off the bat when Jerry said 'Let's dump Ian's mod_gz into the core!' which is what started this whole entire thread. Ask him what he thinks now :-) Knowing Ryan, he is probably fine with adding it at this point. Nope. My opinion hasn't changed. I won't veto, but I continue to think this is a bad idea. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: mod_include performance update
On Wed, 2001-09-05 at 00:45, Eli Marmor wrote: Brian Pane wrote: http://webperf.org/a2/v25/ From that page: Tests run on the 9 of September I guess that one of the tools that Apache is using now, is Time Machine ;-) Or the year is 2000? ;-) doing 3 things at the same time. ;-) One phenomenon in the truss data looks a bit strange: http://webperf.org/a2/v25/truss.2001_01_04 http://webperf.org/a2/v25/truss.2001_09_04 This page doesn't exist. P.S. Aside from those narrow minded notes, I must say that your work looks impressive! (Is Mike Abott present anywhere?) doubt it. -- Ian Holsman [EMAIL PROTECTED] Performance Measurement Analysis CNET Networks - (415) 364-8608
Re: sub requests are all GETs
Whoa, deja vu... I could have sworn I fixed something very similar to this more than 5 years ago now. In fact, here is the patch for Apache 1.2.x: Fri Mar 1 03:01:06 1996 UTC (66 months, 1 week ago) http://cvs.apache.org/viewcvs.cgi/apache-1.2/src/http_request.c.diff?r1=1.2r2=1.3 Not exactly the same issue, I know, but very close. -Rasmus On Wed, 5 Sep 2001, Eric Prud'hommeaux wrote: Can anybody explain why ap_set_sub_req_protocol does rnew-method = GET; rnew-method_number = M_GET; instead of rnew-method = r-method; rnew-method_number = r-method_number; ? The consequence is that functions like negotiation sub_req = ap_sub_req_lookup_file(dirent.name, r, NULL); check auth on the wrong method. You can check this by POSTing to foo and having a limit on POST for foo.php3 (as opposed to the whole directory). A quick way to check is to set a breakpoint in ap_set_sub_req_protocol and telnet localhost 80 POST /Overview HTTP/1.0 Content-Length: 5 abcd Any calls to the auth modules will have a method of GET despite the POST action they will eventually execute. All auth modules and the like could check for this: int method = r-main ? r-main-method_number : r-method_number; but it seems better to have the sub request default to the method of the request that inspired it. There may be some modules that may count on the default behavior, like mod_include, but I think they should specifically make the new method be a GET as they are not duplicating the parent request's behaviour.
Re: cvs commit: httpd-2.0 configure.in
On Wednesday 05 September 2001 09:40, [EMAIL PROTECTED] wrote: trawick 01/09/05 09:40:35 Modified:.configure.in Log: on AIX we need to pass in --disable-shared to apr and apr-util configurations; otherwise we get goofy executable files obviously libtool isn't doing the right thing, but I don't know what that is If you pass in --disable-shared with libtool 1.4, you will remove the ability to create shared modules. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: remaining CPU bottlenecks in 2.0
Greg Stein wrote: On Tue, Sep 04, 2001 at 11:56:48PM -0500, William A. Rowe, Jr. wrote: ... You were discussing the possibility of parsing for !--# as a skip by 5. Consider jumping to a 4 byte alignment, truncating to char and skip by dwords. E.g., you only have to test for three values, not four, and you can use the machine's most optimal path. But I'd ask if strstr() isn't optimized on the platform, why are we reinventing it? strstr() can't find strings that span a bucket boundary. In addition, the most promising search algorithms for this problem require a lookup table that contains metadata about the search pattern. We can save time by precomputing the lookup table for !--# at server startup (or even at compile time), which is something that strstr() can't do. --Brian
RE: [PATCH] Add mod_gz to httpd-2.0
After 3-4 years we know exactly how you work. Peter -Original Message- From: Rodent of Unusual Size [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 05, 2001 11:58 AM To: [EMAIL PROTECTED] Subject: Re: [PATCH] Add mod_gz to httpd-2.0 [EMAIL PROTECTED] wrote: Ian... are you a committer? What do you say about adding ZLIB to Apache source ASAP. Yea or nay? This only demonstrates your non-understanding of how we work, and/or how to work with us. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ All right everyone! Step away from the glowing hamburger!
Re: zlib inclusion and mod_gz(ip) recap
On Wed, 5 Sep 2001, Ryan Bloom wrote: Ryan himself said he prefers 3 right off the bat when Jerry said 'Let's dump Ian's mod_gz into the core!' which is what started this whole entire thread. Ask him what he thinks now :-) Knowing Ryan, he is probably fine with adding it at this point. Nope. My opinion hasn't changed. I won't veto, but I continue to think this is a bad idea. i have the same opinion, for the same reason i was stunned (and still am) to see ldap modules in the 2.0 tree. new modules at this point are only going to further delay the release of 2.0, hell even discussing adding new modules is contributing to the delay. i do think apache should be bundled with one or the other (mod_gz or mod_gzip), but it should wait until 2.1. i'm pretty sure most people (myself included), are most interested in being able to just use 2.0 feature-wise as-is and won't mind waiting until 2.1+ for new features. we're in the 9th month of year 2001, i saw the first glimpse of a '2.0' server in early 1996 (rob thau's), i have no problem waiting longer for bug fixes, performance, doing things right, etc., but there is no good reason to add new modules or big features at this point. they should wait for 2.1+. fitting quote from mod_ssl.h: /* ``The Apache Group: a collection of talented individuals who are trying to perfect the art of never finishing something.'' -- Rob Hartill */
Re: zlib inclusion and mod_gz(ip) recap
Doug MacEachern wrote: we're in the 9th month of year 2001, i saw the first glimpse of a '2.0' server in early 1996 (rob thau's), i have no problem waiting longer for bug fixes, performance, doing things right, etc., but there is no good reason to add new modules or big features at this point. they should wait for 2.1+. Then where is the v2.1 development tree? v2.0 represents the latest bleeding egde server development. Until a v2.1 development tree exists then there is no choice but to commit things to v2.0. Regards, Graham -- - [EMAIL PROTECTED]There's a moon over Bourbon Street tonight... S/MIME Cryptographic Signature
Re: zlib inclusion and mod_gz(ip) recap
On Wednesday 05 September 2001 11:09, Graham Leggett wrote: Doug MacEachern wrote: we're in the 9th month of year 2001, i saw the first glimpse of a '2.0' server in early 1996 (rob thau's), i have no problem waiting longer for bug fixes, performance, doing things right, etc., but there is no good reason to add new modules or big features at this point. they should wait for 2.1+. Then where is the v2.1 development tree? v2.0 represents the latest bleeding egde server development. Until a v2.1 development tree exists then there is no choice but to commit things to v2.0. That is bunk. If you want to start 2.1, then just say so, and we can create a 2.1 repository. I would warn you that doing that means you have to keep the two in sync, which sucks, big time. Otherwise, just commit mod_gzip to an external repository, and add a note to the 2.0 STATUS file that when we go to 2.1, it should be moved to the 2.1 tree. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: [PATCH] Add mod_gz to httpd-2.0
Peter J. Cranstone wrote: After 3-4 years we know exactly how you work. Oh? Then what is the explanation for Kevin publicly soliciting an individual to do something that recent discussion has shown the group considers moot? Regardless of facts, it is perception that matters. Not speaking for anyone else, my perception of the practises in which you and Kevin have seemingly engaged makes me personally wary and unwilling to take anything you write at face value. Little things, like Kevin's post just now, and the multiplicity of 'I'm not with RC' mail origins a couple of years ago, and the overall tenor of your posts.. I try very hard to keep an open mind; when I committed to you to get you a session at ApacheCon to talk about generic content compression issue, I meant it -- but was overruled 4 to 1. Despite my best efforts at open-mindedness, something about your collective tactics and polemic keeps making me want to close my mind against you. And I suspect (but do not know) that others have the same perception, which may have been the cause of that 4-1 vote. Most people I take at face value -- but you seem to change positions so much that I feel I cannot but suspect you of having a hidden agenda. Maybe you do not, and maybe you do -- and maybe it is no more than trying to get RC's package into the Apache distribution because of the marketing bulge that would give RC. But.. maybe it is more than that. I cannot tell, and you have not made it easy to tell, and I am not sure I would blindly accept it if you did. This is not technical, this is social and political. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ All right everyone! Step away from the glowing hamburger!
Re: zlib inclusion and mod_gz(ip) recap
On Wed, 5 Sep 2001, Graham Leggett wrote: v2.0 represents the latest bleeding egde server development. Until a v2.1 development tree exists then there is no choice but to commit things to v2.0. for new modules? no, you create a separate tree for the new module (either on apache.org or sourceforge or your own laptop or wherever). if the httpd-2.0 tree needs tweaking for smooth integration of a new module, that's fine.
Re: zlib inclusion and mod_gz(ip) recap
Doug MacEachern wrote: for new modules? no, you create a separate tree for the new module (either on apache.org or sourceforge or your own laptop or wherever). if the httpd-2.0 tree needs tweaking for smooth integration of a new module, that's fine. That's wonderful news for users. No longer do they download the tarball, build it, and enable the features they want, now they trawl the web looking for this module and that module - assuming they even know the modules exist in the first place. We need to keep things simple from a user perspective, and not just focus on keeping things simple from a developers perspective. Regards, Graham -- - [EMAIL PROTECTED]There's a moon over Bourbon Street tonight... S/MIME Cryptographic Signature
Coredump in mod-include (INTERNALLY generated...
hi. just wondering if anyone care's for Cliff's fix to this core dump that he posted a while back ..Ian -- Ian Holsman [EMAIL PROTECTED] Performance Measurement Analysis CNET Networks - (415) 364-8608
Re: zlib inclusion and mod_gz(ip) recap
On Wednesday 05 September 2001 11:27, Graham Leggett wrote: Doug MacEachern wrote: for new modules? no, you create a separate tree for the new module (either on apache.org or sourceforge or your own laptop or wherever). if the httpd-2.0 tree needs tweaking for smooth integration of a new module, that's fine. That's wonderful news for users. No longer do they download the tarball, build it, and enable the features they want, now they trawl the web looking for this module and that module - assuming they even know the modules exist in the first place. We need to keep things simple from a user perspective, and not just focus on keeping things simple from a developers perspective. What trawl the web? Register the thing with modules.apache.org, and then all users just go there. If modules.apache.org isn't good enough, then let's fix that problem. Again, rolling EVERY possible module into one Apache dist is not the solution to the module problem. It is a band-aid to the problem. If the only reason to include the module in the core is so that users don't have to trawl the web, then I will veto it right now. That is NOT a valid reason to include the module in the core IMNSHO. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: Coredump in mod-include (INTERNALLY generated...
On Wed, Sep 05, 2001 at 11:28:59AM -0700, Ian Holsman wrote: hi. just wondering if anyone care's for Cliff's fix to this core dump that he posted a while back I think OtherBill said he was going to fix this the right way. I forget what the right way is. I think he's in an airplane now, so I dunno what his timetable is. -- justin
Re: Coredump in mod-include (INTERNALLY generated...
On 5 Sep 2001, Ian Holsman wrote: hi. just wondering if anyone care's for Cliff's fix to this core dump that he posted a while back I never even convinced _myself_ that it was the Right Way, since the whole purpose of the INTERNALLY GENERATED FUBAR r-uri is that there might not even be a uri for the file if it's in a different directory. That part makes sense. You can mask the behavior with my patch, and sometimes it works, but I'm willing to bet that if you gave it a file with no valid URI that it'd puke. My patch only fixes (works around) the cases *I've* thought up, which isn't very many. =-) I have no idea what the Right Way is. --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: sub requests are all GETs
Eric Prud'hommeaux wrote: Can anybody suggest a reason that sub request methods would _not_ default to the parent requests method? Well, consider the situation of the parent request using POST. When you constructed your subrequest you would need to also provide an entity-body or explicitly set Content-length to zero. I suspect one of the original arguments may have been that GET and HEAD are defined as idempotent and therefore essentially repeatable and transparent to the effect of the original request. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ All right everyone! Step away from the glowing hamburger!
Re: mod_include performance update
Bill Stoddard wrote: One phenomenon in the truss data looks a bit strange: http://webperf.org/a2/v25/truss.2001_01_04 The server appears to be logging the request (the write to file descriptor 4) before closing its connection to the client (the shutdown that follows the write). For a non-keepalive request, shouldn't it do the shutdown first? Nah, what you are seeing is normal. The socket is shutdown and closed during the call to ap_lingering_close in the MPMs. That's the way it should work. That sounds like a bug to me. The client shouldn't have to wait for the logger to run before the request completes. --Brian
Re: [PATCH] Round 2 of mod_include/find_start_sequence...
On Wed, 2001-09-05 at 12:10, Rasmus Lerdorf wrote: On Wed, 5 Sep 2001, Justin Erenkrantz wrote: Replaced Rabin-Karp with the bndm algorithm as implemented by Sascha. Seems to work. i'll crank up the benchmark boxes I used to test the other versions with .. I'll have an answer to that in ~1 hour Is it faster? -- Ian Holsman [EMAIL PROTECTED] Performance Measurement Analysis CNET Networks - (415) 364-8608
Re: [PATCH] Round 2 of mod_include/find_start_sequence...
Rasmus Lerdorf wrote: On Wed, 5 Sep 2001, Justin Erenkrantz wrote: Replaced Rabin-Karp with the bndm algorithm as implemented by Sascha. Seems to work. Is it faster? I just tried this patch, and I'm seeing a 10% throughput improvement on Linux in some lightweight testing, compared to the original find_start_sequence. --Brian
Re: mod_include performance update
Bill Stoddard wrote: One phenomenon in the truss data looks a bit strange: http://webperf.org/a2/v25/truss.2001_01_04 The server appears to be logging the request (the write to file descriptor 4) before closing its connection to the client (the shutdown that follows the write). For a non-keepalive request, shouldn't it do the shutdown first? Nah, what you are seeing is normal. The socket is shutdown and closed during the call to ap_lingering_close in the MPMs. That's the way it should work. That sounds like a bug to me. The client shouldn't have to wait for the logger to run before the request completes. You may not like the design, but it's not a bug. Keep in mind, completing the HTTP request is not the same thing as closing the socket. Making the client wait an extra couple of millisconds for the server to close the socket is a non-issue. Not flushing our output buffers before logging... now that would be a bug. Bill
RE: [PATCH] Add mod_gz to httpd-2.0
I suppose the only thing we can do is contribute. Kevin has, mod_gzip was released under an ASF license which was approved by the ASF Board. If there is a hidden agenda there then you're better than I at spotting it. Mod_gzip is available for 1.3.x It will be available for 2.x when you hit beta. It will contain the same license as before. There are no patents, TM's or anything else associated with it. We will continue to support both versions. Now tell me where the hidden agenda is. If it's not technical, then it's social (you just plain don't like us... Not a problem) or political (the powers that be don't like us... Again not a problem) From a political standpoint I'm pissed that Covalent Technologies can cut a deal with Compaq for the new Compaq Apache server (wonder if it will ship with or without compression (details are tough to find on this whole deal). But you know what, more power to Ryan and his crew for doing something like that. Did I ever see a vote for something like that, no... I even checked the ASF minutes... Nothing since February. Whatever. This whole conversation is mute, include, exclude, revoke whatever, mod_gzip will always be available from Kevin and I and we will support it. If you don't include it, all it means is another click to our website. Later... Peter -Original Message- From: Rodent of Unusual Size [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 05, 2001 12:20 PM To: [EMAIL PROTECTED] Subject: Re: [PATCH] Add mod_gz to httpd-2.0 Peter J. Cranstone wrote: After 3-4 years we know exactly how you work. Oh? Then what is the explanation for Kevin publicly soliciting an individual to do something that recent discussion has shown the group considers moot? Regardless of facts, it is perception that matters. Not speaking for anyone else, my perception of the practises in which you and Kevin have seemingly engaged makes me personally wary and unwilling to take anything you write at face value. Little things, like Kevin's post just now, and the multiplicity of 'I'm not with RC' mail origins a couple of years ago, and the overall tenor of your posts.. I try very hard to keep an open mind; when I committed to you to get you a session at ApacheCon to talk about generic content compression issue, I meant it -- but was overruled 4 to 1. Despite my best efforts at open-mindedness, something about your collective tactics and polemic keeps making me want to close my mind against you. And I suspect (but do not know) that others have the same perception, which may have been the cause of that 4-1 vote. Most people I take at face value -- but you seem to change positions so much that I feel I cannot but suspect you of having a hidden agenda. Maybe you do not, and maybe you do -- and maybe it is no more than trying to get RC's package into the Apache distribution because of the marketing bulge that would give RC. But.. maybe it is more than that. I cannot tell, and you have not made it easy to tell, and I am not sure I would blindly accept it if you did. This is not technical, this is social and political. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ All right everyone! Step away from the glowing hamburger!
Re: [PATCH] Add mod_gz to httpd-2.0
I really should just ignore this. But oh well From a political standpoint I'm pissed that Covalent Technologies can cut a deal with Compaq for the new Compaq Apache server (wonder if it will ship with or without compression (details are tough to find on this whole deal). But you know what, more power to Ryan and his crew for doing something like that. Did I ever see a vote for something like that, no... I even checked the ASF minutes... Nothing since February. Whatever. a) This is not Ryan and his crew. I am an engineering manager at Covalent. I have 0 control over partnerships and the like. b) Why does this deal piss you off? Covalent and Compaq are partnering to promote the use of Apache and Compaq hardware with Linux in the marketplace. They were looking for an company to partner with to help, and for Apache that was us. c) Right now, the solution does not include compression at all. That may change in the future, but I don't know of any plans along those lines. d) This has nothing to do with the ASF, so the ASF wasn't involved. Covalent sells a version of Apache (with only EAPI patches applied), and proprietary modules. We do not need to check with the ASF to partner with a company that wants our help to do the same basic thing. If RemoteCommunications wants to sell Apache, feel free, you don't need ASF permission to do so. You do need to follow the license, which Covalent does. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: [PATCH] Add mod_gz to httpd-2.0
Okay, I'll bite. On Wed, Sep 05, 2001 at 01:46:55PM -0600, Peter J. Cranstone wrote: [Snip: nothing that hasn't been said in this thread before] If it's not technical, then it's social (you just plain don't like us... Not a problem) or political (the powers that be don't like us... Again not a problem) From a political standpoint I'm pissed that Covalent Technologies can cut a deal with Compaq for the new Compaq Apache server (wonder if it will ship with or without compression (details are tough to find on this whole deal). But you know what, more power to Ryan and his crew for doing something like that. Did I ever see a vote for something like that, no... I even checked the ASF minutes... Nothing since February. Whatever. Why are you dragging this into the discussion? I can't see that it has anything to do with it. Anyone else seeing this as a bad thing for Apache? I don't see why they shouldn't be allowed to do this, anyone should be able to do this, even your company. But do you have the expertise? Looking at the License of Apache it doesn't make it sound like they wouldn't be able to do so, as long as they state like written in the license: This product includes software developed by the Apache Group for use in the Apache HTTP server project (http://www.apache.org/). Which I am quite sure they will, Covalent will probably use every chance they get to promote Apache. The reason why there might not be more information on this deal than what Covalents website gives[1] might be that the rest is to be worked out? When I heard this I was kind of happy for Apache, 'cause it can only be a good thing if Covalent gets a deal like this. More money, more likely that Ryan, Randy, Dough, William, etc. will keep up their very good work on Apache. my $cent = 2; [1] http://www.covalent.net/company/press/news-20010828.php -- Thomas Eibner
RE: [PATCH] Add mod_gz to httpd-2.0
Guys, Conversation is over. I have nothing more to add. This whole conversation is degenerating into meaningless nonsense. Someone else can carry the thread. Peter -Original Message- From: Thomas Eibner [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 05, 2001 2:21 PM To: [EMAIL PROTECTED] Subject: Re: [PATCH] Add mod_gz to httpd-2.0 Okay, I'll bite. On Wed, Sep 05, 2001 at 01:46:55PM -0600, Peter J. Cranstone wrote: [Snip: nothing that hasn't been said in this thread before] If it's not technical, then it's social (you just plain don't like us... Not a problem) or political (the powers that be don't like us... Again not a problem) From a political standpoint I'm pissed that Covalent Technologies can cut a deal with Compaq for the new Compaq Apache server (wonder if it will ship with or without compression (details are tough to find on this whole deal). But you know what, more power to Ryan and his crew for doing something like that. Did I ever see a vote for something like that, no... I even checked the ASF minutes... Nothing since February. Whatever. Why are you dragging this into the discussion? I can't see that it has anything to do with it. Anyone else seeing this as a bad thing for Apache? I don't see why they shouldn't be allowed to do this, anyone should be able to do this, even your company. But do you have the expertise? Looking at the License of Apache it doesn't make it sound like they wouldn't be able to do so, as long as they state like written in the license: This product includes software developed by the Apache Group for use in the Apache HTTP server project (http://www.apache.org/). Which I am quite sure they will, Covalent will probably use every chance they get to promote Apache. The reason why there might not be more information on this deal than what Covalents website gives[1] might be that the rest is to be worked out? When I heard this I was kind of happy for Apache, 'cause it can only be a good thing if Covalent gets a deal like this. More money, more likely that Ryan, Randy, Dough, William, etc. will keep up their very good work on Apache. my $cent = 2; [1] http://www.covalent.net/company/press/news-20010828.php -- Thomas Eibner
Re: [PATCH] Add mod_gz to httpd-2.0
From a political standpoint I'm pissed that Covalent Technologies can cut a deal with Compaq for the new Compaq Apache server (wonder if it will ship with or without compression (details are tough to find on this whole deal). This is news to me, and certainly no permission has been given to either Compaq nor Covalent to call anything a 'Compaq Apache server.' I am on the ASF board and I can tell you this has not come before us. I should point out that AFAIK, Compaq Apache server is not a product name that I have ever heard before. A quick look at Compaq's web site also does not come up with that name anywhere. If somebody does find that name as a product anyplace, please let me know ASAP. However, Covalent knows very well what we can and can not call products, so I can't imagine that we would use that name. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: Lost connection
Daniel Abad wrote: In my apache server, when I start it, I lost the connection with the network. This is not the best place for this sort of question. I recommend the [EMAIL PROTECTED] mailing list. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ All right everyone! Step away from the glowing hamburger!
RE: [PATCH] Add mod_gz to httpd-2.0
If somebody does find that name as a product anyplace, please let me know ASAP. It was on a recent CNET release: http://news.cnet.com/news/0-1003-200-6963955.html Compaq Computer has signed a deal with Covalent Technology to jointly develop and market Covalent's Apache Web server software, the companies plan to announce Monday. -Original Message- From: Ryan Bloom [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 05, 2001 2:27 PM To: [EMAIL PROTECTED]; Rodent of Unusual Size Subject: Re: [PATCH] Add mod_gz to httpd-2.0 From a political standpoint I'm pissed that Covalent Technologies can cut a deal with Compaq for the new Compaq Apache server (wonder if it will ship with or without compression (details are tough to find on this whole deal). This is news to me, and certainly no permission has been given to either Compaq nor Covalent to call anything a 'Compaq Apache server.' I am on the ASF board and I can tell you this has not come before us. I should point out that AFAIK, Compaq Apache server is not a product name that I have ever heard before. A quick look at Compaq's web site also does not come up with that name anywhere. If somebody does find that name as a product anyplace, please let me know ASAP. However, Covalent knows very well what we can and can not call products, so I can't imagine that we would use that name. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: [PATCH] Add mod_gz to httpd-2.0
Peter J. Cranstone wrote: Conversation is over. I have nothing more to add. This whole conversation is degenerating into meaningless nonsense. Someone else can carry the thread. This clever technique of ducking out of the conversation rather than answering pointed questions is just *so* endearing, Peter. And it is one of the tactics to which I alluded earlier as making me wary of your motives. You bring something up, we question you about it, you say the conversation is meaningless. You made remarks, statements, and allegations -- stand up to them. As for 'nothing more to add' -- well, you could add the answers to the questions you have been asked.. But you do have one thing partly right, IMO -- trying to converse with you seems to frequently be an exercise in futility. That is a social issue, and if the rest of the group cannot have a reasonable conversation with a module developer, no technical merit of the module is going to overcome the irritation and frustration the rest of the group is going to experience if it gets included. So, in short, if you have any interest in mod_gzip being included, stop behaving like an ass and *converse*. 'Conversation over,' forsooth! -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ All right everyone! Step away from the glowing hamburger!
RE: [PATCH] Add mod_gz to httpd-2.0
Ken, Kiss my ass... I have work to do. You want to continue the conversation take it off line you know where I am. Peter -Original Message- From: Rodent of Unusual Size [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 05, 2001 2:42 PM To: [EMAIL PROTECTED] Subject: Re: [PATCH] Add mod_gz to httpd-2.0 Peter J. Cranstone wrote: Conversation is over. I have nothing more to add. This whole conversation is degenerating into meaningless nonsense. Someone else can carry the thread. This clever technique of ducking out of the conversation rather than answering pointed questions is just *so* endearing, Peter. And it is one of the tactics to which I alluded earlier as making me wary of your motives. You bring something up, we question you about it, you say the conversation is meaningless. You made remarks, statements, and allegations -- stand up to them. As for 'nothing more to add' -- well, you could add the answers to the questions you have been asked.. But you do have one thing partly right, IMO -- trying to converse with you seems to frequently be an exercise in futility. That is a social issue, and if the rest of the group cannot have a reasonable conversation with a module developer, no technical merit of the module is going to overcome the irritation and frustration the rest of the group is going to experience if it gets included. So, in short, if you have any interest in mod_gzip being included, stop behaving like an ass and *converse*. 'Conversation over,' forsooth! -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ All right everyone! Step away from the glowing hamburger!
Re: [PATCH] Add mod_gz to httpd-2.0
Peter J. Cranstone wrote: It was on a recent CNET release: http://news.cnet.com/news/0-1003-200-6963955.html Compaq Computer has signed a deal with Covalent Technology to jointly develop and market Covalent's Apache Web server software, the companies plan to announce Monday. Thank you for the reference. Yes, that is phrased ambiguously; it can either be taken as Covalent owning Apache, or Covalent's software *for* Apache. I expect Ryan will have someone contact C!NET about it. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ All right everyone! Step away from the glowing hamburger!
Re: [PATCH] Add mod_gz to httpd-2.0
Peter J. Cranstone wrote: Kiss my ass... And now to the invective. I have work to do. Which apparently does not include answering questions about your previous posts. Well, you did answer one of the ones about the 'Compaq Apache Server' thing, so thanks for that. You want to continue the conversation take it off line you know where I am. No, thanks. I have nothing to hide, so I will keep my remarks and responses right here in the public eye. If you have something you want to say privately, you can send to *me* offline, and I will keep it private. You know, you are showing a definite talent for moving me from 'wary' to 'hostile.' -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ All right everyone! Step away from the glowing hamburger!
Re: [PATCH] Add mod_gz to httpd-2.0
In a message dated 01-09-05 14:16:59 EDT, Marc Slemko wrote... This is not technical, this is social and political. Then keep it off the forum... you fucking didactic self-righteous asshole. When was the last fucking time you posted anything useful? Send your 'social and political' commentary to us privately. You know where we are. Yours... Kevin Kiley BTW: Seen the latest press release regarding Covalent and Compaq? Any comments for those boys?
Re: zlib inclusion and mod_gz(ip) recap
In a message dated 01-09-05 14:28:29 EDT, you write: That's wonderful news for users. No longer do they download the tarball, build it, and enable the features they want, now they trawl the web looking for this module and that module - assuming they even know the modules exist in the first place. That's the way it's always been. Your users are used to it. Every tried to install mod_ssl for 1.3.x? They will kiss your foot once you simply make sure they don't have to go through that bullshit anymore. Anything else is icing on the cake. We need to keep things simple from a user perspective, and not just focus on keeping things simple from a developers perspective. The I suggest you only assault them with multithreading and filtering on a first go-around with your ( 5 years in the making ) new release. Those 2 alone are going to be hard enough for them to get configured correctly. Heck... there aren't even a whole lotta developers on the forum that know how to set up the filtering right yet. Yours... Kevin Kiley
Re: zlib inclusion and mod_gz(ip) recap
In a message dated 01-09-05 14:44:54 EDT, Marc Selmko wrote... And your motives are entirely altruistic? Why do I have problems with that? See, if you were going about this right it would not be RC versus AG, it would be 'us'. See previous message reagrding 'didactic self-righteous asshole'. Also see previous message regarding any comment about recent Covalent/Compaq deal and/or similar deals going on right under your motive-sniffing nose. None of us have to ever come here at all. ( See... I used US... that means EVERYONE... happy now? ). The pay is too low. If we ever show our faces here at all it's because we want to be here. Yours... Kevin Kiley
Re: [PATCH] Add mod_gz to httpd-2.0
In a message dated 01-09-05 14:16:59 EDT, Marc wrote... After 3-4 years we know exactly how you work. Oh? Then what is the explanation for Kevin publicly soliciting an individual to do something that recent discussion has shown the group considers moot? I asked him what he 'thought', asshole. Are you seriously telling me you think I can't come onto this PUBLIC forum for a non-profit organization and ask someone what their opinon is? Give me a fucking break. Yours... Kevin Kiley
Re: [PATCH] Add mod_gz to httpd-2.0
In a message dated 01-09-05 16:14:01 EDT, you write: This is news to me, and certainly no permission has been given to either Compaq nor Covalent to call anything a 'Compaq Apache server.' I am on the ASF board and I can tell you this has not come before us. Actually... it's called the 'Covalent Apache Web Server'. There isn't anything in your board meeting minutes that authorizes that, either. Not complaining... just pointing out a fact. I am with Peter on this. More power to them. Randy Terbrush hasn't appeared here for awhile but there is no question he should benefit financially from his early work with Apache. Ryan and Dirk and Harrie and Doug and Daniel and Jon and Bill Wrowe ( others?... Apache contibutors all ) deserve the same. I hope they all get to buy their own private island following the recent Compaq deal the timing of which was perfect since the valuation of the jsut announced Compaq and Hewlett-Packet merger is in the neighborhood of 25 BILLION ( With a B ) dollars. Again... more power to all. Randy and William Rowe alone have busted their ASSES trying to give you 2.0. I hope they both get private jets out of the deal. Later... Kevin Kiley
Re: zlib inclusion and mod_gz(ip) recap
[EMAIL PROTECTED] wrote: That's the way it's always been. Your users are used to it. What do you mean your users? *I* am a user, and complex configuration pisses *me* off. I am also a webmaster, and have had to put up with the Apache + mm + mod_ssl + auth_ldap + mod_perl nonsense for ages. I expect v2.0 as a new generation of software to be significantly easier to handle than v1.3 was. Regards, Graham -- - [EMAIL PROTECTED]There's a moon over Bourbon Street tonight... S/MIME Cryptographic Signature
Re: [PATCH] Add mod_gz to httpd-2.0
[EMAIL PROTECTED] wrote: In a message dated 01-09-05 14:16:59 EDT, Marc Slemko wrote... This is not technical, this is social and political. Then keep it off the forum... you fucking didactic self-righteous asshole. As I said, invective time. As I also said, except to Peter alone, you are showing a definite talent for changing my opinion toward RC from 'wary' to 'hostile.' I guess you are now included.. Sorry to disappoint you, but it *belongs* in this forum. Whether the group as a whole can get along with you, or cannot, is extremely relevant. When was the last fucking time you posted anything useful? 'What have you done for me lately', eh? And the relevance is..? I have been busy with ApacheCon, so I guess I am not entitled to have an opinion on technical matters any more? Or on how the project operates? Send your 'social and political' commentary to us privately. You know where we are. That would be pointless, since I would only be expressing my own opinions and you would be the only ones to tell me I was wrong (if I were, and I may be). Stalemate. Here everyone has a chance to comment. I have been willing to cut you guys slack from the beginning, but that ends now. Get along with the people here, or go away. That is my opinion. BTW: Seen the latest press release regarding Covalent and Compaq? Any comments for those boys? Yep; read my other replies in this thread. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ All right everyone! Step away from the glowing hamburger!
Re: [PATCH] Add mod_gz to httpd-2.0
[EMAIL PROTECTED] wrote: In a message dated 01-09-05 16:14:01 EDT, you write: This is news to me, and certainly no permission has been given to either Compaq nor Covalent to call anything a 'Compaq Apache server.' I am on the ASF board and I can tell you this has not come before us. Actually... it's called the 'Covalent Apache Web Server'. There isn't anything in your board meeting minutes that authorizes that, either. If it says that anywhere on the product, or on Covalent's or Compaq's sites, then the board will ask that it be changed. However, if you are basing this solely on the C!NET article, I do not think that it authoritative enough to warrant any action at all; asking C!NET to clarify would not accomplish much. I do not think that either Covalent or Compaq are using that name, however, and it is a non-issue if they are not. I see Randy has already responded. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ All right everyone! Step away from the glowing hamburger!
RE: [PATCH] Add mod_gz to httpd-2.0
From: Peter J. Cranstone [mailto:[EMAIL PROTECTED]] Kiss my ass... *delurk* That'll motivate three +1's for mod_gz real quick. :^) (No need for anyone to reply. Just cluttering the list with sophomoric humor.) -Charels
Re: [PATCH] Add mod_gz to httpd-2.0
[EMAIL PROTECTED] wrote: Do you moonlight as a preacher or something? Nope. Do you judge everyone around you like this? Considering that it was an observation rather than a judgement, I suppose I can say that yes, I make observations like that all the time. If you want to 'converse' with Peter then book a flight to Denver. This is EMAIL. No one can ever say all they want to or exepct anyone to ever read it all. It's like 100 different pen-pal sessions going on at the same time. Somehow the rest of us manage to communicate fairly well, though. Of course, sometimes we have to have face-to-face meetings to clear up misunderstandings. :-) And when someone is asked a question, he generally answers, or at least does not take offense when asked repeatedly. I've been reading this forum for 4 years and I certainly don't pretend that anyone here is 'my friend'. Well, I think I am not alone in observing that some of the people here *are* 'my friends.' Why does it work for me (and possibly others) and not you? This is business. Peter made some statements and refused to clarify when asked. Sorry, but if that is business it doesn't sound like *good* business to me. But that is just my opinion, and possibly worthless if it works for RC elsewhere. It may be business to RC, but I think it probably is *not* business for a lot of other people here. Which might be the basis for some of the disconnects. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ All right everyone! Step away from the glowing hamburger!
Re: zlib inclusion and mod_gz(ip) recap
In a message dated 01-09-05 17:29:58 EDT, you write: True enough for everyone. (Except any who might be here as a job assignment.) The question I asked was, 'Why do you want to be here?' An answer of 'none of your business' is perfectly acceptable (though probably not constructive), and certainly preferable to pointless insults that do not address the question. Mr... I don't owe you or anyone else any fucking explanations for why I choose to contribute to a public domain software project. Get off your pulpit. No one here is asking to be my 'friend' nor am I asking for the same in return. You guys want my code... and you will probably get it even after all this bullshit from bored guys like you sitting in a cubicle somewhere. Code talks... bullshit walks. That's always been the Apache way... am I right? mod_gzip for Apache 1.3.x kicks ass and so will the 2.0 version. It is a HUGE benefit to a lot of working stiffs out there and in the current economic climate we have 'thank you' emails from poor slobs all over the world whose bandwidth is now cut in half and they can survive without having to pay telco bills they can't afford. Yours... Kevin Kiley
Re: [PATCH] Add mod_gz to httpd-2.0
In a message dated 01-09-05 17:43:30 EDT, you write: From: Peter J. Cranstone [mailto:[EMAIL PROTECTED]] Kiss my ass... *delurk* That'll motivate three +1's for mod_gz real quick. :^) (No need for anyone to reply. Just cluttering the list with sophomoric humor.) -Charels No problem, Charels... This all just reminds me of some tense board meeting and someone finally cracks a joke and the room breaks out laughing. People are getting some things off their chest here and that's a good thing. It'll be back to business soon enough. Later... Kevin
Re: zlib inclusion and mod_gz(ip) recap
[EMAIL PROTECTED] wrote: Mr... I don't owe you or anyone else any fucking explanations for why I choose to contribute to a public domain software project. True enough; thanks for answering the question. I was actually asking abour RC, but forget it. Get off your pulpit. How about a swap? Take the chip off your shoulder. You guys want my code... That is not decided. If we do want the code, it is probably with you or someone else from RC along to maintain it. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ All right everyone! Step away from the glowing hamburger!
Covalent Apache Web Server
In a message dated 01-09-05 16:14:01 EDT, Kevin Kiley wrote... This is news to me, and certainly no permission has been given to either Compaq nor Covalent to call anything a 'Compaq Apache server.' I am on the ASF board and I can tell you this has not come before us. Actually... it's called the 'Covalent Apache Web Server'. There isn't anything in your board meeting minutes that authorizes that, either. Not complaining... just pointing out a fact. I am with Peter on this. More power to them. Randy Terbrush hasn't appeared here for awhile but there is no question he should benefit financially from his early work with Apache. Ryan and Dirk and Harrie and Doug and Daniel and Jon and Bill Wrowe ( others?... Apache contibutors all ) deserve the same. I hope they all get to buy their own private island following the recent Compaq deal the timing of which was perfect since the valuation of the jsut announced Compaq and Hewlett-Packet merger is in the neighborhood of 25 BILLION ( With a B ) dollars. Again... more power to all. Randy and William Rowe alone have busted their ASSES trying to give you 2.0. I hope they both get private jets out of the deal. Later... Kevin Kiley Errata... Sorry about that... what I meant to say was... Ryan Bloom and William Rowe alone have busted their ASSES trying to give you 2.0. I hope they both get private jets out of the deal. I am sure Randy Terbrush ( founder and CTO of Covalent ) has worked JUST as hard as anyone else to make Covalent what it is today and secure the Compaq deal and to forward the progress of Apache 2.0 but I specifically meant to mention 'Ryan and William'. Yours... Kevin
Re: [PATCH] Round 2 of mod_include/find_start_sequence...
[ Bringing this back on-list where it belongs... ] On Wed, Sep 05, 2001 at 03:37:42PM -0700, Brian Pane wrote: Ian Holsman wrote: On Wed, 2001-09-05 at 15:20, Brian Pane wrote: Ian Holsman wrote: Ok.. test is in there now... with justin's patch. I haven't tested the functionality of it, but the performance looks good. Yes indeed. Any idea how this code compares to your skip-5 implementation? * looks much neater. * just optimizes the 'start_tag', which make it's life easier. * does the same kind of thing as the skip-5 * the edge case is handled the 'slow' way..which is good, as it gets around most of the buggy crap I had in my stuff * why is it compiling the pattern inside of the 'find_start_sequence' this could be done 'postconfig' or in 'child_init' I'm lazy? I'll clean it up and post it once more to the list to give people a chance to review before I commit. This is a pretty big change, but I think we're going in the right direction though. otherwise +1 Coolie. (Although your vote isn't binding, it is valuable feedback.) [ Brian's comments ] Sounds good. Two concerns: * Should we run it through Quantify? (As good as the reduction in usr CPU in the graphs is, I'm slightly surprised that it's not even better.) I'll wait until we have some Quantify numbers to ensure that this is a better performing algorithm. This is also with Sascha's hacked up implementation of bndm. Someone who knows the bndm algorithm well should verify it. (It looks like it works from everything I can tell...) * We seem to have hit a wall at ~250 requests/second in the mstone environment with includes, ~300 without. I'm worried that there may be another bottleneck somewhere else in the server. (But figuring that out needn't get in the way of Justin's patch.) Be curious to see why. I wonder if the time is still spent in find_start_sequence now. Ideally, as we uncover bottlenecks, we should just find more. We keep going until we find no more. =) -- justin
Re: zlib inclusion and mod_gz(ip) recap
Hello all... Due to comments made in a private email to myself and my company from one of your top level board members this is to inform everyone that we can stop this nonsense right now because there will BE no submission of mod_gzip for Apache 2.0 to this group. It shall remain a ( fully supported ) 3rd party module and will be released, as we have said from day one, the moment this group has enough confidence in their own product to release it. It only takes one veto to stop the inclusion and it has been expressed. You can go ahead and drop mod_gz in right now. It's all you've got. Later... Kevin
There will be no mod_gzip included in 2.0
Hello all... Due to comments made in a private email to myself and my company from one of your top level board members this is to inform everyone that we can stop this nonsense right now because there will BE no submission of mod_gzip for Apache 2.0 to this group. It shall remain a ( fully supported ) 3rd party module and will be released, as we have said from day one, the moment this group has enough confidence in their own product to release it. It only takes one veto to stop the inclusion and it has been expressed. You can go ahead and drop mod_gz in right now. It's all you've got. Later... Kevin
[PATCH] Take 3 of mod_include patch...
Okay, I've cleaned this up and I think it is ready for commit.
However, I'd really like some eyes on this. =-)
In Ian and Brian's testing, this does seem to make mod_include
faster. I can't guarantee that there aren't any bugs here,
but I've tested it with what I have and looked at the code as
best as I can. I think this gets us moving in the right
direction.
Changes since last post:
- don't call strlen on the static string (thanks Cliff!)
- move the compilation of the starting_sequence to post_config
- comment (well, tried to...)
- fixed some of the parameters to fit our type conventions.
Comments? Can someone who has knowledge of the bndm algorithm
verify this? I'll try glancing at the paper tonight or tomorrow.
-- justin
Index: modules/filters/mod_include.c
===
RCS file: /home/cvs/httpd-2.0/modules/filters/mod_include.c,v
retrieving revision 1.143
diff -u -r1.143 mod_include.c
--- modules/filters/mod_include.c 2001/09/04 02:13:58 1.143
+++ modules/filters/mod_include.c 2001/09/05 23:39:18
@@ -206,6 +206,113 @@
/* --- Parser functions --- */
+/* This is an implementation of the BNDM search algorithm.
+ *
+ * Fast and Flexible String Matching by Combining Bit-parallelism and
+ * Suffix Automata (2001)
+ * Gonzalo Navarro, Mathieu Raffinot
+ *
+ * http://www-igm.univ-mlv.fr/~raffinot/ftp/jea2001.ps.gz
+ *
+ * Initial code submitted by Sascha Schumann.
+ */
+
+typedef struct {
+unsigned int T[256];
+unsigned int x;
+} bndm_t;
+
+/* This is the pattern matcher that holds the STARTING_SEQUENCE bndm_t
+ * structure.
+ */
+static bndm_t start_seq_pat;
+
+/* Precompile the bndm_t data structure. */
+static void bndm_compile(bndm_t *t, const char *n, apr_size_t nl)
+{
+unsigned int x;
+const char *ne = n + nl;
+
+memset(t-T, 0, sizeof(unsigned int) * 256);
+
+for (x = 1; n ne; x = 1)
+t-T[(unsigned char) *n++] |= x;
+
+t-x = x - 1;
+}
+
+/* Implements the BNDM search algorithm (as described above).
+ *
+ * n - the pattern to search for
+ * nl - length of the pattern to search for
+ * h - the string to look in
+ * hl - length of the string to look for
+ * t - precompiled bndm structure against the pattern
+ *
+ * Returns the count of character that is the first match or hl if no
+ * match is found.
+ */
+static int bndm(const char *n, apr_size_t nl, const char *h, apr_size_t hl,
+bndm_t *t)
+{
+apr_size_t skip;
+const char *he, *p, *pi;
+unsigned int *T, x, d;
+
+he = h + hl;
+
+T = t-T;
+x = t-x 1;
+
+pi = h - 1; /* pi: p initial */
+p = pi + nl; /* compare window right to left. point to the first char */
+
+do {
+skip = nl;
+d = x;
+do {
+d = (d 1) T[(unsigned char) *p--];
+if ((d 1)) {
+if (p != pi)
+skip = p - pi;
+else
+return p - h + 1;
+}
+} while (d 1);
+p = (pi += skip) + nl;
+} while (p he);
+
+return hl;
+}
+
+/* We've now found a start sequence tag... */
+static apr_bucket* found_start_sequence(apr_bucket *dptr,
+ include_ctx_t *ctx,
+ int tagStart)
+{
+/* We want to split the bucket at the ''. */
+ctx-state = PARSE_DIRECTIVE;
+ctx-tag_length = 0;
+ctx-parse_pos = 0;
+ctx-tag_start_bucket = dptr;
+ctx-tag_start_index = tagStart;
+if (ctx-head_start_index 0) {
+apr_bucket *tmp_bkt;
+
+/* Split the bucket with the start of the tag in it */
+apr_bucket_split(ctx-head_start_bucket, ctx-head_start_index);
+tmp_bkt = APR_BUCKET_NEXT(ctx-head_start_bucket);
+/* If it was a one bucket match */
+if (dptr == ctx-head_start_bucket) {
+ctx-tag_start_bucket = tmp_bkt;
+ctx-tag_start_index = tagStart - ctx-head_start_index;
+}
+ctx-head_start_bucket = tmp_bkt;
+ctx-head_start_index = 0;
+}
+return ctx-head_start_bucket;
+}
+
/* This function returns either a pointer to the split bucket containing the
* first byte of the BEGINNING_SEQUENCE (after finding a complete match) or it
* returns NULL if no match found.
@@ -217,8 +324,8 @@
const char *c;
const char *buf;
const char *str = STARTING_SEQUENCE;
-apr_bucket *tmp_bkt;
-apr_size_t start_index;
+int slen = sizeof(STARTING_SEQUENCE) - 1;
+int pos;
*do_cleanup = 0;
@@ -269,8 +376,53 @@
if (len == 0) { /* end of pipe? */
break;
}
+
+/* Set our buffer to use. */
c = buf;
-while (c buf + len) {
+
+/* The last bucket had a left over partial match that we need to
+ * complete.
+ */
+if (ctx-state == PARSE_HEAD)
+{
Re: There will be no mod_gzip included in 2.0
[EMAIL PROTECTED] wrote: Due to comments made in a private email to myself and my company from one of your top level board members this is to inform everyone that we can stop this nonsense right now because there will BE no submission of mod_gzip for Apache 2.0 to this group. I suspect that mine was the private message that caused this. People who wanted mod_gzip can execrate and blame me for it, and that is the only reason I am posting this -- so people know whom to blame if they want to do so. I do not intend to post any more on this topic. The 'veto' above is how RC chooses to interpret my 'probably' statement below; what I said privately was, in part, So when it comes down to it, despite any technical merits, I will probably vote against RC simply because I think you are excellent examples of non-team-players and Ian (or just about anyone else) would be easier to deal with. You do not answer questions, you duck and cover and handwave, and you resort to ad hominem attacks, both of you. and RC chooses to regard that as a veto, even though not expressed as such and not on the list. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ All right everyone! Step away from the glowing hamburger!
Re: [PATCH] Take 3 of mod_include patch...
Justin Erenkrantz wrote:
[...]
+/* Implements the BNDM search algorithm (as described above).
+ *
+ * n - the pattern to search for
+ * nl - length of the pattern to search for
+ * h - the string to look in
+ * hl - length of the string to look for
+ * t - precompiled bndm structure against the pattern
+ *
+ * Returns the count of character that is the first match or hl if no
+ * match is found.
+ */
+static int bndm(const char *n, apr_size_t nl, const char *h, apr_size_t hl,
+bndm_t *t)
+{
+apr_size_t skip;
+const char *he, *p, *pi;
+unsigned int *T, x, d;
+
+he = h + hl;
+
+T = t-T;
+x = t-x 1;
+
+pi = h - 1; /* pi: p initial */
+p = pi + nl; /* compare window right to left. point to the first char */
+
+do {
+skip = nl;
+d = x;
+do {
+d = (d 1) T[(unsigned char) *p--];
+if ((d 1)) {
+if (p != pi)
+skip = p - pi;
+else
+return p - h + 1;
+}
+} while (d 1);
+p = (pi += skip) + nl;
+} while (p he);
If nl hl (e.g., if the caller tries to search for a 5-byte pattern in
a 3-byte string), the first loop iteration will look at memory beyond
the end of the string. Should this be a while loop instead of do-while?
(Or is the caller responsible for avoiding this case?)
--Brian
Re: [PATCH] Take 3 of mod_include patch...
On Wed, Sep 05, 2001 at 06:46:45PM -0700, Brian Pane wrote:
Justin Erenkrantz wrote:
[...]
+/* Implements the BNDM search algorithm (as described above).
+ *
+ * n - the pattern to search for
+ * nl - length of the pattern to search for
+ * h - the string to look in
+ * hl - length of the string to look for
+ * t - precompiled bndm structure against the pattern
+ *
+ * Returns the count of character that is the first match or hl if no
+ * match is found.
+ */
+static int bndm(const char *n, apr_size_t nl, const char *h, apr_size_t hl,
+bndm_t *t)
+{
+apr_size_t skip;
+const char *he, *p, *pi;
+unsigned int *T, x, d;
+
+he = h + hl;
+
+T = t-T;
+x = t-x 1;
+
+pi = h - 1; /* pi: p initial */
+p = pi + nl; /* compare window right to left. point to the first char */
+
+do {
+skip = nl;
+d = x;
+do {
+d = (d 1) T[(unsigned char) *p--];
+if ((d 1)) {
+if (p != pi)
+skip = p - pi;
+else
+return p - h + 1;
+}
+} while (d 1);
+p = (pi += skip) + nl;
+} while (p he);
If nl hl (e.g., if the caller tries to search for a 5-byte pattern in
a 3-byte string), the first loop iteration will look at memory beyond
the end of the string. Should this be a while loop instead of do-while?
(Or is the caller responsible for avoiding this case?)
Good point. I'll make it a while loop instead. If we start out past
the end of h, we know we don't have a match. For mod_include, the
edge cases should pick up if that is part of a tag spanning buckets.
-- justin
Re: [PATCH] Take 3 of mod_include patch...
On Wed, Sep 05, 2001 at 07:11:37PM -0700, Justin Erenkrantz wrote:
On Wed, Sep 05, 2001 at 06:46:45PM -0700, Brian Pane wrote:
Justin Erenkrantz wrote:
[...]
+/* Implements the BNDM search algorithm (as described above).
+ *
+ * n - the pattern to search for
+ * nl - length of the pattern to search for
+ * h - the string to look in
+ * hl - length of the string to look for
+ * t - precompiled bndm structure against the pattern
+ *
+ * Returns the count of character that is the first match or hl if no
+ * match is found.
+ */
+static int bndm(const char *n, apr_size_t nl, const char *h, apr_size_t hl,
+bndm_t *t)
+{
+apr_size_t skip;
+const char *he, *p, *pi;
+unsigned int *T, x, d;
+
+he = h + hl;
+
+T = t-T;
+x = t-x 1;
+
+pi = h - 1; /* pi: p initial */
+p = pi + nl; /* compare window right to left. point to the first char */
+
+do {
+skip = nl;
+d = x;
+do {
+d = (d 1) T[(unsigned char) *p--];
+if ((d 1)) {
+if (p != pi)
+skip = p - pi;
+else
+return p - h + 1;
+}
+} while (d 1);
+p = (pi += skip) + nl;
+} while (p he);
If nl hl (e.g., if the caller tries to search for a 5-byte pattern in
a 3-byte string), the first loop iteration will look at memory beyond
the end of the string. Should this be a while loop instead of do-while?
(Or is the caller responsible for avoiding this case?)
Good point. I'll make it a while loop instead. If we start out past
the end of h, we know we don't have a match. For mod_include, the
edge cases should pick up if that is part of a tag spanning buckets.
Actually, I think the conditional should be:
while (p = he)
Thoughts? We're scanning R-L, so p points to the end of the string.
It is possible to have !--# as n (which should match). -- justin
Re: [PATCH] Take 3 of mod_include patch...
On Wed, Sep 05, 2001 at 07:15:13PM -0700, Justin Erenkrantz wrote: Actually, I think the conditional should be: while (p = he) Thoughts? We're scanning R-L, so p points to the end of the string. It is possible to have !--# as n (which should match). -- justin No. I'm wrong. I'll shut up now. It should be while (p he). he points past the end of the string. -- justin
Re: [PATCH] Take 3 of mod_include patch...
Justin Erenkrantz wrote: [...] Actually, I think the conditional should be: while (p = he) Thoughts? We're scanning R-L, so p points to the end of the string. It is possible to have !--# as n (which should match). -- justin I think (p he) is still the right conditional; 'he' points to the address right after the end of the string to be scanned (because of the initialization he = h + hl). --Brian
Re: [PATCH] Take 3 of mod_include patch...
On Wed, Sep 05, 2001 at 06:42:10PM -0700, john sachs wrote: i applied this patch and the mod_include test fails in the same spot as it has been. content file has: !--#include file=extra/inc-extra1.shtml-- 'include file' with relative path to file not in same path as the file you are requesting. Well, in my defense, my patch wasn't supposed to fix *that*. But, while I'm in there, I'll take a shot at trying to fix this as OtherBill hasn't had a chance to yet. =-) -- justin
Re: Add mod_gz to httpd-2.0 ( Thread restart )
On Wed, Sep 05, 2001 at 08:05:27PM -0700, Ian Holsman wrote: Some performance results with mod_gz are available at http://webperf.org/a2/v25/ (no core dumps.. pages look ok on a real browser while running test) I'm going to be re-running the tests for a longer period to see if there are memory leaks (as well as quantify/purify on it next week) brief summary: * numbers are based on pages going through mod-include * once of the runs looks a bit flaky.. and I'm re-running it * cpu usage (USR) is VERY high (from 100 without gz to 500) * page requests down 16% when using GZ * page resposne times are slower with GZ, but have a lower deviation The expectation is that the network bandwidth used should be much lower. The tradeoff is that the CPU should get nailed. -- justin
[PATCH] Fix relative internal file...
$.10 hack. Works for me.
The other solutions would require a rewrite of the logic. That
is something I don't have time to do and I also bet that OtherBill
has ideas about how to fix this the right way. Or not. =-)
-- justin
Index: server/request.c
===
RCS file: /home/cvs/httpd-2.0/server/request.c,v
retrieving revision 1.48
diff -u -r1.48 request.c
--- server/request.c2001/09/01 05:21:16 1.48
+++ server/request.c2001/09/06 03:11:00
@@ -1581,9 +1581,7 @@
* either, if the base paths match, we can pick up where we leave off.
*/
-if (strncmp(rnew-filename, fdir, fdirlen) == 0
-rnew-filename[fdirlen]
-ap_strchr_c(rnew-filename + fdirlen, '/') == NULL)
+if (strncmp(rnew-filename, fdir, fdirlen) == 0 rnew-filename[fdirlen])
{
char *udir = ap_make_dirstr_parent(rnew-pool, r-uri);
Re: remaining CPU bottlenecks in 2.0
Justin Erenkrantz wrote: [...] * The discussion here covers only CPU utilization. There are other aspects of performance, like multiprocessor scalability, that are independent of this data. Once we get the syscalls optimized (I'm reminded of Dean's attack on our number of syscalls in 1.3 - I believe he went through syscall by syscall trying to eliminate all of the unnecessary ones), I think the next performance point will be MP scalability (see below for lock scalability on solaris). But, we do need to see what we can do about optimizing the syscalls though... The syscall profile for 2.0 looks close to optimal (as long as you disable .htaccess files and symlink checking). We're doing a few too many gettimeofday calls per request, though; I 'll investigate whether any of these can be optimized away. (Fortunately, gettimeofday is cheap compared to time(2).) [...] * _lwp_mutex_unlock() gets from pthread_mutex_unlock(), but only from a small fraction of pthread_mutex_unlock calls (Can someone familiar with Solaris threading internals explain this one?) The LWP scheduler may also call _lwp_mutex_unlock() implicitly - LWP scheduler is a user-space library so it gets thrown in with our numbers I bet. Here's some background on Solaris's implementation that I think may provide some useful information as to how the locks will perform overall. (If you spot any inconsistencies, it is probably my fault...I'm going to try to explain this as best as I can...) First off, Solaris has adaptive locks. Depending if the owner of the lock is currently active, it will spin. If the system sees that the owner of the held lock is not currently active, it will sleep (they call this an adaptive lock - it now enters a turnstile). Ah, I guess that explains why only a small fraction of pthread_mutex_lock calls on Solaris seem to result in calls to lwp_mutex_lock: in the fast case where the lock is available, it just stays in user-mode code? --Brian
Re: [PATCH] Take 3 of mod_include patch...
On Wed, 5 Sep 2001, john sachs wrote: i applied this patch and the mod_include test fails in the same spot as it has been. content file has: !--#include file=extra/inc-extra1.shtml-- 'include file' with relative path to file not in same path as the file you are requesting. Yep. This patch has no effect on that. It's probably not mod_include that needs patching, but rather the core. I was hoping OtherBill could enlighten us on what the Right Way to fix it is... because I have very little idea myself. Last I heard, Bill suggested we just set r-uri=NULL in that case and just test for (r-uri) in all places we use r-uri, rather than setting r-uri to some bogus string. I'm all for it, if we're convinced that that's the right thing to do. I'll take a stab at patching it that way tomorrow just for grins. --Cliff
Re: Add mod_gz to httpd-2.0 ( Thread restart )
Justin Erenkrantz wrote: On Wed, Sep 05, 2001 at 08:05:27PM -0700, Ian Holsman wrote: Some performance results with mod_gz are available at http://webperf.org/a2/v25/ (no core dumps.. pages look ok on a real browser while running test) I'm going to be re-running the tests for a longer period to see if there are memory leaks (as well as quantify/purify on it next week) brief summary: * numbers are based on pages going through mod-include * once of the runs looks a bit flaky.. and I'm re-running it * cpu usage (USR) is VERY high (from 100 without gz to 500) * page requests down 16% when using GZ * page resposne times are slower with GZ, but have a lower deviation The expectation is that the network bandwidth used should be much lower. The tradeoff is that the CPU should get nailed. -- justin (put another 10 minute gzip run on the site.. this doesn't have the spike in the middle) to put the CPU usage in perspective. we were running hotter than this with mod-include ~1 week ago. (before brian's justin's patches) ..Ian
Re: remaining CPU bottlenecks in 2.0
On Wed, Sep 05, 2001 at 08:19:50PM -0700, Brian Pane wrote: Ah, I guess that explains why only a small fraction of pthread_mutex_lock calls on Solaris seem to result in calls to lwp_mutex_lock: in the fast case where the lock is available, it just stays in user-mode code? Yes. -- justin
Re: remaining CPU bottlenecks in 2.0
I got 1 more question about the solaris implementation of the Threaded/Worker MPM. should we be called the setconcurrency flag on startup ? I know solaris figures it out along the way, but a bit of gentle prodding never hurt. ..Ian Brian Pane wrote: Justin Erenkrantz wrote: [...] * The discussion here covers only CPU utilization. There are other aspects of performance, like multiprocessor scalability, that are independent of this data. Once we get the syscalls optimized (I'm reminded of Dean's attack on our number of syscalls in 1.3 - I believe he went through syscall by syscall trying to eliminate all of the unnecessary ones), I think the next performance point will be MP scalability (see below for lock scalability on solaris). But, we do need to see what we can do about optimizing the syscalls though... The syscall profile for 2.0 looks close to optimal (as long as you disable .htaccess files and symlink checking). We're doing a few too many gettimeofday calls per request, though; I 'll investigate whether any of these can be optimized away. (Fortunately, gettimeofday is cheap compared to time(2).) [...] * _lwp_mutex_unlock() gets from pthread_mutex_unlock(), but only from a small fraction of pthread_mutex_unlock calls (Can someone familiar with Solaris threading internals explain this one?) The LWP scheduler may also call _lwp_mutex_unlock() implicitly - LWP scheduler is a user-space library so it gets thrown in with our numbers I bet. Here's some background on Solaris's implementation that I think may provide some useful information as to how the locks will perform overall. (If you spot any inconsistencies, it is probably my fault...I'm going to try to explain this as best as I can...) First off, Solaris has adaptive locks. Depending if the owner of the lock is currently active, it will spin. If the system sees that the owner of the held lock is not currently active, it will sleep (they call this an adaptive lock - it now enters a turnstile). Ah, I guess that explains why only a small fraction of pthread_mutex_lock calls on Solaris seem to result in calls to lwp_mutex_lock: in the fast case where the lock is available, it just stays in user-mode code? --Brian
Re: [PATCH] Fix relative internal file...
On Wed, 5 Sep 2001, Justin Erenkrantz wrote: $.10 hack. Works for me. The other solutions would require a rewrite of the logic. That is something I don't have time to do and I also bet that OtherBill has ideas about how to fix this the right way. Or not. =-) -if (strncmp(rnew-filename, fdir, fdirlen) == 0 -rnew-filename[fdirlen] -ap_strchr_c(rnew-filename + fdirlen, '/') == NULL) +if (strncmp(rnew-filename, fdir, fdirlen) == 0 rnew-filename[fdirlen]) This won't work, I'll bet, for the same reason my hack won't work. All you've done is cause the mod_include httpd-test test to pass by getting it into the then instead of the else, which is the exact same thing my hack did. Both will break if you have a relative path that goes UP at least one directory first, since the strncmp will fail. You'll get back into the else case and segfault again. Rather than working around the else, which is there for a reason, we need to patch the REST of the code to be aware of the existance of the else case. The easiest way to do that is probably to change the else case to set r-uri NULL instead of to INTERNALLY GENERATED fooness and test r-uri before using it in all places it's used. --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: [PATCH] Fix relative internal file...
On Wed, Sep 05, 2001 at 11:34:24PM -0400, Cliff Woolley wrote: hack did. Both will break if you have a relative path that goes UP at least one directory first, since the strncmp will fail. You'll get back At least with mod_include, that can never happen. It makes sure that there are no ../ (or whatever for that OS) in a file directive. -- justin
Re: [PATCH] Fix relative internal file...
On Wed, 5 Sep 2001, Justin Erenkrantz wrote: On Wed, Sep 05, 2001 at 11:34:24PM -0400, Cliff Woolley wrote: hack did. Both will break if you have a relative path that goes UP at least one directory first, since the strncmp will fail. You'll get back At least with mod_include, that can never happen. It makes sure that there are no ../ (or whatever for that OS) in a file directive. Hmmm... thought required. That else case HAS to be there for a reason. I'll do some research. --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: remaining CPU bottlenecks in 2.0
On Wed, Sep 05, 2001 at 08:34:30PM -0700, Ian Holsman wrote: I got 1 more question about the solaris implementation of the Threaded/Worker MPM. should we be called the setconcurrency flag on startup ? I know solaris figures it out along the way, but a bit of gentle prodding never hurt. Aaron and I went back and forth on this. He was of the mind that the user scheduler should figure it out after a period of time (and that we shouldn't muck with it). The badness happens in testthread.c - Solaris executes that code in serial since the user scheduler never has a chance to interrupt and balance the threads. But, in the real code, Solaris balances it since we hit syscalls and mutexes quite often. An equivalent to calling pthread_setconcurrency is to use /usr/lib/lwp/libthread.so instead of /usr/lib/libthread.so. -- justin
Re: Add mod_gz to httpd-2.0 ( Thread restart )
On Wed, Sep 05, 2001 at 08:07:26PM -0700, Justin Erenkrantz wrote: On Wed, Sep 05, 2001 at 08:05:27PM -0700, Ian Holsman wrote: Some performance results with mod_gz are available at http://webperf.org/a2/v25/ (no core dumps.. pages look ok on a real browser while running test) I'm going to be re-running the tests for a longer period to see if there are memory leaks (as well as quantify/purify on it next week) brief summary: * numbers are based on pages going through mod-include * once of the runs looks a bit flaky.. and I'm re-running it * cpu usage (USR) is VERY high (from 100 without gz to 500) * page requests down 16% when using GZ What does this mean? Total bytes transferred? If so, then why only 16% The number of page requests should be constant, unless mod_gz introduces some kind of caching. * page resposne times are slower with GZ, but have a lower deviation The expectation is that the network bandwidth used should be much lower. The tradeoff is that the CPU should get nailed. -- justin Also: latency should increase and delivery time should decrease. cheers, -g -- Greg Stein, http://www.lyra.org/
Re: [PATCH] Fix relative internal file...
On Wed, 5 Sep 2001, Greg Stein wrote: I don't understand what you're trying to solve here, and how this solves it. It's an attempt to fix the mod_include !--#include file=foo/bar.html-- segfault. It solves it by setting r-uri to something valid rather than setting it to INTERNALLY GENERATED It's as yet unclear as to whether it's a correct solution, though. I'm looking into it. --Cliff
Re: zlib inclusion and mod_gz(ip) recap
On Wed, 5 Sep 2001, Graham Leggett wrote: That's wonderful news for users. No longer do they download the tarball, build it, and enable the features they want, now they trawl the web looking for this module and that module - assuming they even know the modules exist in the first place. We need to keep things simple from a user perspective, and not just focus on keeping things simple from a developers perspective. 'no longer' ? ldap and gzip were never part of the 1.3 bundle. have you not seen apachetoolbox.com? according the site 63 3rd party modules are included. are you suggesting we add all of those to the httpd-2.0 bundle to keep things simple? that project solves the problems you site here, i assume they will do the same for 2.0 once it is released. anyhow, you've totally missed my point. my only concern is timing. i'm not at suggesting which modules should or should not be part of the core. i'm only saying it should have been decided long ago which modules are going into the 2.0 core. anything else should wait for 2.1+.
Re: zlib inclusion and mod_gz(ip) recap
On Wed, Sep 05, 2001 at 11:05:50AM -0700, Doug MacEachern wrote: On Wed, 5 Sep 2001, Ryan Bloom wrote: Ryan himself said he prefers 3 right off the bat when Jerry said 'Let's dump Ian's mod_gz into the core!' which is what started this whole entire thread. Ask him what he thinks now :-) Knowing Ryan, he is probably fine with adding it at this point. Nope. My opinion hasn't changed. I won't veto, but I continue to think this is a bad idea. i have the same opinion, for the same reason i was stunned (and still am) to see ldap modules in the 2.0 tree. That was a surprise to me, too. I was out during July. I thought we would have some simple ldap stuff in APRUTIL... not a huge codebase in httpd. (when I discussed a division of the code, I was expecting a separate vote for adding mod_ldap to httpd-2.0, which I would then vote against :-) Since then, I had also thought we agreed to move mod_ldap *out* of the core, into httpd-ldap. To make all of this workable, I just recently posted a thought on how to deal with rollup releases. No comments appeared on that yet, tho. new modules at this point are only going to further delay the release of 2.0, hell even discussing adding new modules is contributing to the delay. If Ian is not assisting with stabilizing the httpd core, then how could his work on mod_gz delay the core? IOW, he is not subtracting anything from the stabilization process. If the argument is that people who *are* stabilizing the core will now be distracted... that is their problem :-) mod_gz is just a little bugger off to the side that the core people don't have to truly worry about. It will get enough attention from the fringe people, if you will (my pardons to people who were just called fringe :-). i do think apache should be bundled with one or the other (mod_gz or mod_gzip), but it should wait until 2.1. i'm pretty sure most people (myself included), are most interested in being able to just use 2.0 feature-wise as-is and won't mind waiting until 2.1+ for new features. Introducing mod_gz isn't going to slow down a 2.0 release. And it *is* a part of RFC 2616, supported by a bunch of browsers, and it is definitely missing functionality (re: its lack was pasted over by mod_perl's and PHP's band-aid solution to compression). we're in the 9th month of year 2001, i saw the first glimpse of a '2.0' server in early 1996 (rob thau's), i have no problem waiting longer for bug fixes, performance, doing things right, etc., but there is no good reason to add new modules or big features at this point. they should wait for 2.1+. If people want a stable server, then they should work on that, and not pay attention to mod_gz within the server. It should be stable enough, and it *does* simply use the existing module and filter interfaces. Why should core people worry about it? It can go in now and be fixed over time. There are a good number of people in this group, and each of those people concentrate on different items, for different reasons. If you want a stable server, with a sooner-than-later release, then concentrate on the core. Some of those other people will work on modules which have *nothing* to do with stability. If the core developers are distracted by mod_gz, then that is their own fault, not the fault of introducing a new module. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: remaining CPU bottlenecks in 2.0
On Tue, 4 Sep 2001, Brian Pane wrote: * Collectively, stat and open comprise 5% of the total CPU time. It would be faster to do open+fstat rather than stat+open (as long as the server is delivering mostly 200s rather than 304s), but that might be too radical a change. Anybody have thoughts on this? linux' dcache makes either method about the same cost, but on other kernels, and especially when NFS is involved (because of how NFS path resolution occurs), the open/fstat is much better. the trick would be to cache open filehandles so that fstat can be used. * memset() is called mostly from apr_pcalloc(), which in turn is used in too many places to yield any easy optimization opportunities. sometimes folks are lazy and ask for zeroed memory out of habit, when they could easily deal with garbage at less cost. -dean
Re: Add mod_gz to httpd-2.0 ( Thread restart )
On Wed, Sep 05, 2001 at 09:15:56PM -0700, Ian Holsman wrote: Greg Stein wrote: On Wed, Sep 05, 2001 at 08:05:27PM -0700, Ian Holsman wrote: Some performance results with mod_gz are available at http://webperf.org/a2/v25/ (no core dumps.. pages look ok on a real browser while running test) I'm going to be re-running the tests for a longer period to see if there are memory leaks (as well as quantify/purify on it next week) brief summary: * numbers are based on pages going through mod-include * once of the runs looks a bit flaky.. and I'm re-running it * cpu usage (USR) is VERY high (from 100 without gz to 500) * page requests down 16% when using GZ What does this mean? Total bytes transferred? If so, then why only 16% The number of page requests should be constant, unless mod_gz introduces some kind of caching. the number of concurrent requests are constant in all of these tests. we have 50 processes (spread across 10 machines) doing GET's of a page. when a page is retrived is GET's it again (and again..) so if the page response is slower, then the pages/second will also be. we have a more sophisticated comercial machine which can generate better traffic, but it is core dumping at the moment so I can run't the tests through it. Ah! By page requests down... you mean page requests *per second* ?? You omitted that per second, so the statistic made no sense... Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: remaining CPU bottlenecks in 2.0
dean gaudet wrote: [...] * memset() is called mostly from apr_pcalloc(), which in turn is used in too many places to yield any easy optimization opportunities. sometimes folks are lazy and ask for zeroed memory out of habit, when they could easily deal with garbage at less cost. Some good news here: I dug through the profile data and found that over half the httpd's calls to apr_pcalloc are from one function, 'find_entry' in the apr_hash_set implementation. It uses apr_pcalloc to allocate a struct with 5 fields, and then it immediately overwrites 4 of those fields. I'll submit a patch to the APR dev list to fix this. --Brian
[STATUS] (apache-1.3) Wed Sep 5 23:45:05 EDT 2001
APACHE 1.3 STATUS: -*-text-*- Last modified at [$Date: 2001/08/21 15:30:28 $] Release: 1.3.21: In development 1.3.20: Tagged and rolled May 15, 2001. Announced May 21, 2001. 1.3.19: Tagged and rolled Feb 26, 2001. Announced Mar 01, 2001. 1.3.18: Not released. (Pulled because of an incorrect unescaping fix. t/r Feb 19, 2001) 1.3.17: Tagged and rolled Jan 26, 2001. Announced Jan 29, 2001. 1.3.16: Not released. (Pulled because of vhosting bug. t/r Jan 20, 2001) 1.3.15: Not released. (Pulled due to CVS dumping core during the tagging when it reached src/os/win32/) 1.3.14: Tagged and Rolled Oct 10, 2000. Released/announced on the 13th. 1.3.13: Not released. (Pulled in the first minutes due to a Netware build bug) 1.3.12: Tagged and rolled Feb. 23, 2000. Released/announced on the 25th. 1.3.11: Tagged and rolled Jan. 19, 2000. Released/announced on the 21st. 1.3.10: Not released. (Pulled at last minute due to a build bug in the MPE port) 1.3.9: Tagged and rolled on Aug. 16. Released and announced on 19th. 1.3.8: Not released. 1.3.7: Not released. 1.3.6: Tagged and rolled on Mar. 22. Released and announced on 24th. 1.3.5: Not released. 1.3.4: Tagged and rolled on Jan. 9. Released on 11th, announced on 12th. 1.3.3: Tagged and rolled on Oct. 7. Released on 9th, announced on 10th. 1.3.2: Tagged and rolled on Sep. 21. Announced and released on 23rd. 1.3.1: Tagged and rolled on July 19. Announced and released. 1.3.0: Tagged and rolled on June 1. Announced and released on the 6th. 2.0 : In alpha development, see httpd-2.0 repository RELEASE SHOWSTOPPERS: ab is broken on many platforms. Dirk has offered patch, it does not apply cleanly, he has offered to clean this up. RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP: * htpasswd.c and htdigest.c use tmpnam()... consider using mkstemp() when available. Message-ID: [EMAIL PROTECTED] Status: * Dean's unescaping hell (unescaping the various URI components at the right time and place, esp. unescaping the host name). Message-ID: [EMAIL PROTECTED] Status: * Martin observed a core dump because a ipaddr_chain struct contains a NULL-server pointer when being dereferenced by invoking httpd -S. Message-ID: [EMAIL PROTECTED] Status: Workaround enabled. Clean solution can come after 1.3.19 * long pathnames with many components and no AllowOverride None Workaround is to define Directory / with AllowOverride None, which is something all sites should do in any case. Status: Marc was looking at it. * Ronald Tschalär's patch to mod_proxy to allow other modules to set headers too (needed by mod_auth_digest) Message-ID: [EMAIL PROTECTED] Status: Documentation that needs writing: Available Patches (Most likely, these will not be added to the official 1.3 tree, but instead should be ported to 2.0): * A rewrite of ap_unparse_uri_components() by Jeffrey W. Baker [EMAIL PROTECTED] to more fully close some segfault potential. Message-ID: Pine.LNX.4.21.0102102350060.6815-20@desktop Status: Jim +1 (for 1.3.19), Martin +0 * Patch from C. Bottelier [EMAIL PROTECTED] to run Apache without daemonizing the parent process. PR#7040 Status: fanf +1 (except it needs docs) * Andrew Ford's patch (1999/12/05) to add absolute times to mod_expires Message-ID: [EMAIL PROTECTED] Status: Martin +1, Jim +1, Ken +1 (on concept) * Raymond S Brand's path to mod_autoindex to fix the header/readme include processing so the envariables are correct for the included documents. (Actually, there are two variants in the patch message, for two different ways of doing it.) Message-ID: [EMAIL PROTECTED] Status: Martin +1(concept) * Jayaram's patch (10/27/99) for changes to mod_autoindex Problem 1: AddIcon (alttext,icon) ^^DIRECTORY^^ and AddIcon (alttext,icon) ^^BLANKICON^^ should be able to set the alternate text and icon file for any directory/blankicon in a directory listing. This was not happening because the alternate text for ^^DIRECTORY^^ and ^^BLANKICON^^ were hardcoded to DIR and respectively. Problem 2: - IndexIgnore file-extension should hide the files with this file- extension in directory listings. This was NOT happening because the total filename was being compared with the file-extension. Status: Martin +1(untested), Ken +1(untested) * Salvador Ortiz Garcia [EMAIL PROTECTED]' patch to allow DirectoryIndex to
[STATUS] (httpd-2.0) Wed Sep 5 23:45:09 EDT 2001
APACHE 2.0 STATUS: -*-text-*- Last modified at [$Date: 2001/08/29 18:23:08 $] Release: 2.0.25 : rolled August 29, 2001 2.0.24 : rolled August 18, 2001 2.0.23 : rolled August 9, 2001 2.0.22 : rolled July 29, 2001 2.0.21 : rolled July 20, 2001 2.0.20 : rolled July 8, 2001 2.0.19 : rolled June 27, 2001 2.0.18 : rolled May 18, 2001 2.0.17 : rolled April 17, 2001 2.0.16 : rolled April 4, 2001 2.0.15 : rolled March 21, 2001 2.0.14 : rolled March 7, 2001 2.0a9 : released December 12, 2000 2.0a8 : released November 20, 2000 2.0a7 : released October 8, 2000 2.0a6 : released August 18, 2000 2.0a5 : released August 4, 2000 2.0a4 : released June 7, 2000 2.0a3 : released April 28, 2000 2.0a2 : released March 31, 2000 2.0a1 : released March 10, 2000 Please consult the following STATUS files for information on related projects: * srclib/apr/STATUS * srclib/apr-util/STATUS * docs/STATUS RELEASE SHOWSTOPPERS: * There is a bug in how we sort some hooks, at least the pre-config hook. The first time we call the hooks, they are in the correct order, but the second time, we don't sort them correctly. Currently, the modules/http/config.m4 file has been renamed to modules/http/config2.m4 to work around this problem, it should moved back when this is fixed.rbb * The AddInputFilter and AddOutputFilter directives do not allow the administrator to remove or reorder filters. Once a filter is added in a container, it is present in any subcontainers. It can only be added to the filter chain after any filters specified in enclosing containers. * mod_dir should normally redirect ALL directory requests which do not include a trailing slash on the URI. However, if a notes flag is set (say, via BrowserMatch), this behavior will be disabled for non-GET requests. Status: Greg volunteers MsgId: [EMAIL PROTECTED] MsgId: [EMAIL PROTECTED] * mod_negotiation will not serve a request when an early extention is understood, but a later extention is not. e.g. if the request index.html.bak is recieved, and negotition could find the file index.html.bak.en, it still won't be served because the ap-mime-exception-list will contain index and bak, and the string index.bak doesn't match index.html.bak. Need to review the ap-mime-exception-list component by component to be allow these cases. [This could be part of a patch to allow the name index.bak in the case above to match index.html.bak.en] * mod_negotiation needs a new option or directive, something like ForceLanguagePriority, to fall back to the LanguagePriority directive instead of returning a no acceptable variant error. * Usability: Sanitize the MPM config directives. MaxClients in the threaded MPM is totally misleading now as it has little to do with limiting the number of clients (it limits the number of child processes). Bill proposed nomenclature change to something like StartWorkers, MaxWorkers, etc. that could apply to most all the MPMs (with some notable exceptions). Bill would be happy with changing MaxClients to MaxServers to make it agree with the operation of the StartServers directive. * configure --enable-mods-shared=most option has issues. Example: ./configure --enable-mods-shared=most This builds mod_headers as a DSO (good) but builds mod_mime as a compiled-in module (bad). RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP: * daedalus: mod_cgid and suexec have a problem co-existing. suexec sees a null command string sometimes. The problem happens when you access bugs.apache.org, then click on the search the bug db button. * Win32: Rotatelogs sometimes is not terminated when Apache goes down hard. FirstBill was looking at possibly tracking the child's-child processes in the parent process. * Win32: Add a simple hold console open patch (wait for close or the ESC key, with a nice message) if the server died a bad death (non-zero exit code) in console mode. Resolution: bring forward same ugly hacks from 1.3.13-.20 * Port of mod_ssl to Apache 2.0: The current porting state is summarized in modules/ssl/README. The next step is to figure out how the old three configuration contexts (global, per-server, per-directory) can be ported to Apache 2.0 (especially the global context which has to survive server restarts RSE still does not know how to port). Then the remaining source files (which depend on the configuration contexts) which are still tagged with - in modules/ssl/README can be ported.
