Re: flood-1.0 TR (was: count one bug out...)
On Thu, 5 Sep 2002 08:30:51 -0700 Aaron Bannert [EMAIL PROTECTED] wrote: On Thu, Sep 05, 2002 at 05:29:26PM +0200, Jacek Prucia wrote: - fix install target so we can install flood amd examples off $SRCDIR- fix few more bugs from STATUS (I'm on it) - move tag on changed files and roll tarball I'm ok with whatever anyone else does, since the three of us are the primary consumers of flood-1.0, but in the future (as is my philosophy with the httpd project itself) we shouldn't be doing tag bumps if we can help it. Agreed. An install target would be nice, but we really only have one file that needs to be installed. Besides that we really only have the examples, but no docs or man pages or anything like that. Yeah, but take for example cadaver (ftp-like WebDAV command line client). Install target moves only 2 files around: cadaver binary and man page. Still, it's kinda nice it does what you would expect from install target. All we need for flood install target right now is just: $PREFIX/bin/flood $PREFIX/share/doc/flood/(STATUS|CHANGES|CONFIG|DESIGN|etc.) $PREFIX/share/doc/flood/examples I know that 1.0 is just a number, but most people using software threat it as a special number (stable release). This is why I think flood needs to have install target working before we roll. regards, -- Jacek Prucia 7bulls.com S.A. http://www.7bulls.com/
Re: [PATCH] flood: basic user auth
On Thu, 5 Sep 2002 09:23:37 -0700 Justin Erenkrantz [EMAIL PROTECTED] wrote: On Thu, Sep 05, 2002 at 05:48:51PM +0200, Jacek Prucia wrote: Yep. I was thinking about treating all subsequent requests kinda like separate URL list. Just like a stack.[...] Yeah, a stack is probably the right data structure to use here. I'm not sure if we should detect redirect loops or not. That gets pretty complicated to enforce (mainly because it *is* valid to see a URL twice in one profile). I'd guess I'd prefer it just sitting in an infinite loop rather than trying to test redirect loops unless we have a precise detection algorithm. Aye. I goofed up. I was actually thinking about global config option like: loop-count=4. That option would apply *only* to temporary urllist (forked after 3xx or 401 response). We could mark such temporary urllist and pay close attention to what is going on there, since dead loop could eat up all system resources in no time (if there's nobody around to press Ctrl-C). regards, -- Jacek Prucia 7bulls.com S.A. http://www.7bulls.com/
Re: [PATCH] flood: basic user auth
On Thu, 5 Sep 2002 10:04:59 -0700 Aaron Bannert [EMAIL PROTECTED] wrote: On Wed, Sep 04, 2002 at 10:43:51AM -0700, Justin Erenkrantz wrote: ...and react to WWW-Authenticate header [...] I missed this part of the discussion the other day. I think it would be useful to allow for certain types of dynamic urllist manipulation, but I don't think in general we want to support automatic 302 redirection. Either you are checking for the 302 response and the next entry in your urllist is the same url that came back with the 302, or your app wasn't supposed to return 302. (I tend to think that gratuitous 302's are errors.) An even more complicated example is how flood should deal with the WWW-Authenticate stuff, as suggested above. I tend to think that flood should be able to both check that the auth was required, and that some supplied credentials were accepted. Aye. That is the main reason for urllist juggling. Automatic handling of redirects it's just a benefit. I guess in both cases as long as it can be controlled whether to do automatic 302s or supply auth information, then that's fine. I just tend to think that we don't need it to be automatic. I think it would be nice for flood to follow HTTP RFC, just to be 'HTTP compilant client'. Apache HTTPD server follows HTTP RFC, and flood schouldn't be threated as 'worse' kind of software, that doesn't have to do that. So, how about making flood a little bit more HTTP RFC compilant? :) OTOH I somehow agree with Aaron. I think flood autmatic behaviour schould be an option. Something like 'mimic browser'. We could then use dynamic urllists for other things (like fetching all img's and embed's from response and so on). regards, -- Jacek Prucia 7bulls.com S.A. http://www.7bulls.com/
Re: cvs commit: httpd-test/flood config.h.in flood_round_robin.c
On Fri, Sep 06, 2002 at 10:16:10AM -, [EMAIL PROTECTED] wrote:
@@ -244,7 +247,9 @@
apr_status_t round_robin_create_req(profile_t *profile, request_t *r)
{
round_robin_profile_t *p;
+int crdlen;
char *cookies;
+char *enc_credtls, *credtls, *authz_hdr = NULL;
cookie_t *cook;
p = (round_robin_profile_t*)profile;
@@ -271,6 +276,19 @@
else
cookies = ;
+if (p-url[p-current_url].user) {
+if (!p-url[p-current_url].password) {
+apr_file_printf(local_stderr, missing password for user
'%s'\n, p-url[p-current_url].user);
+return APR_EGENERAL;
+ } else {
One nitpick is that lines shouldn't be over 80 characters. So, the
apr_file_printf should be:
apr_file_printf(local_stderr,
missing password for user '%s'\n,
p-url[p-current_url].user);
We also don't use tabs. Please remove them in favor of spaces.
You might want to take a quick glance at:
http://httpd.apache.org/dev/styleguide.html
+ credtls = apr_pstrcat(r-pool, p-url[p-current_url].user, :,
p-url[p-current_url].password, NULL);
+ crdlen = strlen(credtls);
+ enc_credtls = (char *) apr_palloc(r-pool,
apr_base64_encode_len(crdlen) + 1);
+ apr_base64_encode(enc_credtls, credtls, crdlen);
+ authz_hdr = apr_pstrcat(r-pool, Authorization: Basic ,
enc_credtls, CRLF, NULL);
+ }
+}
+
Since crdlen isn't used outside of this else block, it seems that its
declaration should be inside the else block rather than at the
beginning of the function. And, I'd guess it should be called
credlen - no need to mince one letter.
Looks good though except for these minor nitpicks. =) -- justin
RE: [TALLY] aaa rewrite
On Thu, Sep 05, 2002 at 04:26:22PM -0700, Justin Erenkrantz wrote: aaa rewrite belongs in: 2.0: rbb, brianp, dreid, gstein, jim, rederpj, striker, trawick, ianh, gs, bnicholes 2.1: dpejesh, chris, aaron, hb If someone would like to do a release before I check in the aaa changes, I'd be game to hold off until Monday or Tuesday. (I don't have the time to be an RM right now.) -- justin I would actually like to see a 2.0.41 release. Subversion is seeing problems with working properly against 2.0.40 because of the apr_errno.h changes. If we get a 2.0.41 out there, then we can tell people at least 2.0.41 rather than forcing them to use CVS or a CVS snapshot. I'll try to get the release done over the weekend. Hell... at least a tag. Given a tag, then you can do whatever the heck you want. Cheers, -g +1 Bill
Re: IPv6 capability and name lookup cost
Ian Holsman [EMAIL PROTECTED] writes: A useful performance improvement can be achieved by allowing the administrator to select the following algorithm: lookup IPv4 if at least one IPv4 address was found, we're done lookup IPv6 I know this sounds stupid, but it is usefull to have a option to do it the other way. lookup ipv6 if it's there then use it (we're done) lookup ipv4 that's a natural expansion :) -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: IPv6 capability and name lookup cost
Jeff Trawick [EMAIL PROTECTED] writes: A useful performance improvement can be achieved by allowing the administrator to select the following algorithm: lookup IPv4 if at least one IPv4 address was found, we're done lookup IPv6 Getting more specific, I envision a directive that works like this: NameLookups All|IPv4Okay|IPv6Okay All: current behavior -- tell resolver to find everything IPv4Okay: try IPv4 first, don't look for IPv6 unless no IPv4 addresses found note: if the host is specified in the form of an IPv6 numeric address string, APR will do the right thing IPv6Okay: try IPv6 first, don't look for IPv4 unless no IPv6 addresses found note: if the host is specified in the form of an IPv4 numeric address string, APR will do the right thing (potentially we could add something like this in the future, though I don't think that is necessary now since it is an optimization for an error path: IPv4Only: only look for IPv4 addresses IPv6Only: only look for IPv6 addresses ) I guess core should export the information via a function like ap_get_name_lookup_opts(apr_int32_t *opts) which will set a variable to be OR-ed with any other appropriate apr_sockaddr_info_get() flags to achieve the proper behavior. -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: IPv6 capability and name lookup cost
Looks fine to me. What will the order of the returned matches be for All? IPv4 then IPv6 would be my suggestion which we should be able to do with the changes you're talking about I'd guess. david Jeff Trawick [EMAIL PROTECTED] writes: A useful performance improvement can be achieved by allowing the administrator to select the following algorithm: lookup IPv4 if at least one IPv4 address was found, we're done lookup IPv6 Getting more specific, I envision a directive that works like this: NameLookups All|IPv4Okay|IPv6Okay All: current behavior -- tell resolver to find everything IPv4Okay: try IPv4 first, don't look for IPv6 unless no IPv4 addresses found note: if the host is specified in the form of an IPv6 numeric address string, APR will do the right thing IPv6Okay: try IPv6 first, don't look for IPv4 unless no IPv6 addresses found note: if the host is specified in the form of an IPv4 numeric address string, APR will do the right thing (potentially we could add something like this in the future, though I don't think that is necessary now since it is an optimization for an error path: IPv4Only: only look for IPv4 addresses IPv6Only: only look for IPv6 addresses ) I guess core should export the information via a function like ap_get_name_lookup_opts(apr_int32_t *opts) which will set a variable to be OR-ed with any other appropriate apr_sockaddr_info_get() flags to achieve the proper behavior. -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: El-Kabong -- HTML Parser
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: There are currently two possible avenues. 1) The code goes into apr-util. 2) The code goes into a sandbox project. It makes a lot of sense to have it also in XML as well, together with XERCES-C... Pier
Re: IPv6 capability and name lookup cost
Jeff Trawick [EMAIL PROTECTED] writes: Getting more specific, I envision a directive that works like this: NameLookups All|IPv4Okay|IPv6Okay Can I suggest IPLookups, or something along those lines. That makes it clearer that we are talking about looking up an IP address using a name, and it also differentiates this from HostNameLookups. Joshua.
testing binary builds
In case it is interesting to anybody, I have uploaded a binary build test script to http://www.apache.org/~trawick/testbinbuild.pl. If you have an interest in such issues, take a look (and send me patches for the portions you think suck the most :) ). It doesn't do a whole lot, but it does verify that apxs basically works and that there aren't any bad library dependencies and all the DSOs load. It notices that 2.0.40 and HEAD binary builds are broken on AIX and HP-UX due to library dependency problems because it renames the temporary install directory so that any dependencies on it are found. One of the pitfalls of smoke testing a binary build on the same machine that it was built on is forgetting to rename the directory where libapr, libaprutil, and libexpat were installed. Having that original install dir around masks any hard dependencies on their locations. -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
compatibility with C++ modules
At about the same time recently that I was doing horrible, uncommittable hacks to the build to get Apache 2.0 to support C++ modules on HP-UX, somebody wrote a PR against Apache 1.3 pointing out the same issue I encountered: If httpd is to properly support C++ modules, it may need to be linked with something other than the C compiler front-end, depending on the compiler and the platform. Though we probably don't want to be in the business of pretending to support C++ modules in general, they certainly work with Apache on some platforms and we could at least make it simple for the user to specify the command to invoke to link httpd. This would default to the C compiler, but could be forced by the user to be g++ or aCC or whatever. ? --with-httpd-linker=g++ ? -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: IPv6 capability and name lookup cost
David Reid [EMAIL PROTECTED] writes: Looks fine to me. What will the order of the returned matches be for All? IPv4 then IPv6 would be my suggestion which we should be able to do with the changes you're talking about I'd guess. Alternatively, we could leave it up the the resolver as we do today :) -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: compatibility with C++ modules
So I haven't really looked into how it works, but have you looked at mod_cplusplus? http://sourceforge.net/projects/modcplusplus/ Ryan On 6 Sep 2002, Jeff Trawick wrote: At about the same time recently that I was doing horrible, uncommittable hacks to the build to get Apache 2.0 to support C++ modules on HP-UX, somebody wrote a PR against Apache 1.3 pointing out the same issue I encountered: If httpd is to properly support C++ modules, it may need to be linked with something other than the C compiler front-end, depending on the compiler and the platform. Though we probably don't want to be in the business of pretending to support C++ modules in general, they certainly work with Apache on some platforms and we could at least make it simple for the user to specify the command to invoke to link httpd. This would default to the C compiler, but could be forced by the user to be g++ or aCC or whatever. ? --with-httpd-linker=g++ ? -- ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: compatibility with C++ modules
On Fri, Sep 06, 2002 at 11:55:17AM -0400, Jeff Trawick wrote: Though we probably don't want to be in the business of pretending to support C++ modules in general, they certainly work with Apache on some platforms and we could at least make it simple for the user to specify the command to invoke to link httpd. This would default to the C compiler, but could be forced by the user to be g++ or aCC or whatever. ? --with-httpd-linker=g++ ? LD=g++ ./configure ... ?? (I wondered why this didn't Just Work last time I tried it a few months ago, and stuck it on my todo list to fix it...) -aaron
Re: compatibility with C++ modules
[EMAIL PROTECTED] writes: So I haven't really looked into how it works, but have you looked at mod_cplusplus? http://sourceforge.net/projects/modcplusplus/ just took a look, seems neat -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: compatibility with C++ modules
Aaron Bannert [EMAIL PROTECTED] writes: On Fri, Sep 06, 2002 at 11:55:17AM -0400, Jeff Trawick wrote: Though we probably don't want to be in the business of pretending to support C++ modules in general, they certainly work with Apache on some platforms and we could at least make it simple for the user to specify the command to invoke to link httpd. This would default to the C compiler, but could be forced by the user to be g++ or aCC or whatever. ? --with-httpd-linker=g++ ? LD=g++ ./configure ... ?? definitely a more appropriate user interface, though it seems optimal not to bring any C++ rtl init/term logic into ab, htpasswd, and friends since it would only be necessary for httpd (I wondered why this didn't Just Work last time I tried it a few months ago, and stuck it on my todo list to fix it...) rules.mk is why it doesn't Just Work :) LINK = $(LIBTOOL) --mode=link $(COMPILE) $(LT_LDFLAGS) $(ALL_LDFLAGS) -o $@ -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: IPv6 capability and name lookup cost
Joshua Slive [EMAIL PROTECTED] writes: Jeff Trawick [EMAIL PROTECTED] writes: Getting more specific, I envision a directive that works like this: NameLookups All|IPv4Okay|IPv6Okay Can I suggest IPLookups, or something along those lines. That makes it clearer that we are talking about looking up an IP address using a name, and it also differentiates this from HostNameLookups. makes sense to me :) -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: cvs commit: httpd-2.0/docs/manual index.html.en
aren't all these HTML files autogenerated now ?
I'm just wondering if they belong in CVS at all anymore
[EMAIL PROTECTED] wrote:
slive 2002/09/06 10:19:35
Modified:docs/manual index.html.en
Log:
Woops. Accidentally committed a bad index.html.en. Get back the good one.
Revision ChangesPath
1.38 +141 -113 httpd-2.0/docs/manual/index.html.en
Index: index.html.en
===
RCS file: /home/cvs/httpd-2.0/docs/manual/index.html.en,v
retrieving revision 1.37
retrieving revision 1.38
diff -u -d -b -u -r1.37 -r1.38
--- index.html.en6 Sep 2002 17:15:19 - 1.37
+++ index.html.en6 Sep 2002 17:19:35 - 1.38
@@ -1,180 +1,208 @@
?xml version=1.0 encoding=ISO-8859-1?
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
html xmlns=http://www.w3.org/1999/xhtml; lang=en xml:lang=enhead
-titleApache HTTP Server 2.0 Documentation/titlelink
href=./style/css/manual.css rel=stylesheet media=all type=text/css
title=Main stylesheet /link href=./images/favicon.ico rel=shortcut icon
//headbody id=manual-pagediv id=page-headerp class=menua
href=./mod/ shape=rectModules/a | a href=./mod/directives.html
shape=rectDirectives/a | a href=./faq/ shape=rectFAQ/a | a
href=./glossary.html shape=rectGlossary/a | a href=./sitemap.html
shape=rectSitemap/a/pp class=apacheApache HTTP Server Version 2.0/pimg
alt= src=./images/feather.gif //divdiv class=upa href=./
shape=rectimg title=lt;- alt=lt;- src=./images/left.gif //a/divdiv
id=patha href=http://www.apache.org/; shape=rectApache/a gt; a
href=http://httpd.apache.org/; shape=rectHTTP Server/a gt; a
href=http://httpd.apache.org/docs-project/; shape=rectDocumentation/a gt; a
href=./ sh!
ape=rectVersion 2.0/a/div
-div id=page-contentdiv id=preamble
-h1Apache HTTP Server 2.0 Documentation/h1
+titleApache HTTP Server Version 2.0 Documentation/titlelink
+href=./style/css/manual.css rel=stylesheet media=all
+type=text/css title=Main stylesheet /
+style type=text/css media=all
+!--
+/* undo move content left */
+div#page-content {
+margin-right: 2em;
+padding-right: 0px;
+margin-left: 2em;
+}
+th {
+background-color: #e5ecf3;
+}
+--
+/style
+link
+href=./images/favicon.ico rel=shortcut icon //headbody
+id=manual-pagediv id=page-headerp class=menua
+href=./mod/Modules/a | a
+href=./mod/directives.htmlDirectives/a | a href=./faq/FAQ/a
+| a href=./glossary.htmlGlossary/a | a
+href=./sitemap.htmlSitemap/a/pp class=apacheApache HTTP
+Server Version 2.0/pimg alt= src=./images/feather.gif
+//divdiv class=upa href=./img title=lt;- alt=lt;-
+src=./images/left.gif //a/divdiv id=patha
+href=http://www.apache.org/;Apache/a gt; a
+href=http://httpd.apache.org/;HTTP Server/a gt; a
+href=http://httpd.apache.org/docs-project/;Documentation/a gt; a
+href=./Version 2.0/a/div
-form method=post action=http://search.apache.org/;
enctype=application/x-www-form-urlencoded
- input type=hidden name=what value=httpd.apache.org / input
type=hidden name=results value=20 / input type=hidden name=version
value=2 / input type=text name=keyword size=20 / input type=submit
value=Search /
-/form
+div id=page-content
+h1Apache HTTP Server Version 2.0 Documentation/h1
-table
-trtd rowspan=1 colspan=1
-table
+div align=centerform method=post action=http://search.apache.org/;
+ input type=hidden name=what
+ value=httpd.apache.org / input type=hidden
+ name=results value=20 / input type=hidden
+ name=version value=2 / input type=text
+ name=keyword size=20 / input type=submit
+ value=Search /
+/form/div
+
+
+table style=border: 0
+trtd style=width: 33%
+
+table style=width: 100%
tr
-th rowspan=1 colspan=1Release Notes/th
+thRelease Notes/th
/tr
-tr
-td rowspan=1 colspan=1ul
-lia href=new_features_2_0.html shape=rectNew Features in Version
2.0/a/li
+trtd
+a href=new_features_2_0.htmlNew Features in Version 2.0/a/td/tr
-lia href=upgrading.html shape=rectUpgrading to Version
-2.0/a /li
+trtda href=upgrading.htmlUpgrading to Version
+2.0/a /td/tr
+
+trtda href=LICENSEApache License/a /td
-lia href=LICENSE shape=rectApache License/a /li
-/ul/td
/tr
+trtdnbsp;/td/tr
tr
-th rowspan=1 colspan=1Reference Manual/th
+thReference Manual/th
/tr
-tr
-td rowspan=1 colspan=1ul
-lia href=install.html shape=rectCompiling and
-Installing/a /li
-lia href=invoking.html shape=rectStarting/a /li
+trtda href=install.htmlCompiling
Re: cvs commit: httpd-2.0/docs/manual index.html.en
Ian Holsman wrote: aren't all these HTML files autogenerated now ? I'm just wondering if they belong in CVS at all anymore Ideally, No. (Although that particular one is not auto-generated, the majority are.) There are a couple reasons they are in CVS: 1. To make the release-manager's job easier. I really don't want to make the release manager perform and test the transformation. It is too much work, and there is too much risk of things going wrong. 2. To enable us to better control of what goes live on httpd.apache.org. I'm not really comfortable with transforming live onto the website. It is better to be able to transform in advance and test in a staging area and then do a simple cvs up on the website. Now, this staging area does not necessarily need to be in CVS, but there are some advantages to having it there (easy to see changes and to backup to a known working version, etc). I'm happy to consider alternatives. Joshua.
Releasing 2.0.41
Hi, I hereby volunteer to be RM for 2.0.41. (tag this weekend). Objections? Sander
Re: Releasing 2.0.41
Sander Striker wrote: Hi, I hereby volunteer to be RM for 2.0.41. (tag this weekend). Objections? Sander +1 for tagging this weekend. In the meantime, can the folks with repeatable mod_proxy memory leak cases please try out the latest code in CVS to see if the recent bucket cleanup fixes have solved the problem? Thanks, Brian
Re: Releasing 2.0.41
At 01:43 PM 9/6/2002, Sander Striker wrote: Hi, I hereby volunteer to be RM for 2.0.41. (tag this weekend). Objections? If we say Monday it gives us time to... 1) shake out the new docs nits that folks are raising [and the docs folks are fixing unbelievably quickly!!!] That's going to be the #1 coolest thing about the 2.0.41 for most users. 2) run a few regressions. some folks are still complaining about pdf byteranging on some unix platforms. Undoubtedly, these are broken apr sendfile implementation issues. To best stress this, you need a response constructed of mixed text plus sendfile chunks (such as byterange generates.) There are a few other little bugs that I'd like to fix so that 2.0.41 holds most folks for a month or few. I have no objection if you simply want to use an interim tag so we consume only the bug fixes. But it's possibly easier just to hold off till Monday, if you wouldn't mind. Bill
[PATCH] 1.3 NET_SIZE_T is socklen_t on OpenBSD
Index: src/include/ap_config.h === RCS file: /cvs/src/usr.sbin/httpd/src/include/ap_config.h,v retrieving revision 1.13 diff -u -r1.13 ap_config.h --- src/include/ap_config.h 19 Jul 2002 21:31:15 - 1.13 +++ src/include/ap_config.h 6 Sep 2002 19:16:23 - -692,6 +692,7 #if defined __OpenBSD__ #define HAVE_SYSVSEM_SERIALIZED_ACCEPT #define USE_SYSVSEM_SERIALIZED_ACCEPT +#define NET_SIZE_T socklen_t #endif #define HAVE_FLOCK_SERIALIZED_ACCEPT #define SINGLE_LISTEN_UNSERIALIZED_ACCEPT
Re: Releasing 2.0.41
On Fri, Sep 06, 2002 at 02:12:10PM -0500, William A. Rowe, Jr. wrote: ... There are a few other little bugs that I'd like to fix so that 2.0.41 holds most folks for a month or few. I have no objection if you simply want to use an interim tag so we consume only the bug fixes. But it's possibly easier just to hold off till Monday, if you wouldn't mind. People usually have free time on the weekend, so the release is more easily done then. You can always do a 2.0.42 next week if you'd like. Every time that somebody says hold off just a day, and again, and again, and before you know it, two weeks has passed without a release. Release numbers are cheap; time and volunteering it for a release is expensive. Let's let the RM decide when they'd like to release and work to that schedule. [ and, preferably, work to that also means no cramming in fixes at the last minute, which invariably become bugs :-) ] Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: Releasing 2.0.41
At 02:20 PM 9/6/2002, Greg Stein wrote: On Fri, Sep 06, 2002 at 02:12:10PM -0500, William A. Rowe, Jr. wrote: ... There are a few other little bugs that I'd like to fix so that 2.0.41 holds most folks for a month or few. I have no objection if you simply want to use an interim tag so we consume only the bug fixes. But it's possibly easier just to hold off till Monday, if you wouldn't mind. People usually have free time on the weekend, so the release is more easily done then. You can always do a 2.0.42 next week if you'd like. That works too. Every time that somebody says hold off just a day, and again, and again, and before you know it, two weeks has passed without a release. Release numbers are cheap; time and volunteering it for a release is expensive. Let's let the RM decide when they'd like to release and work to that schedule. [ and, preferably, work to that also means no cramming in fixes at the last minute, which invariably become bugs :-) ] Exactly why I didn't want to toss sendfile fixes in today, only to have them tagged and rolled tomorrow :-) Bill
ap_vformatter (Apache 1.3) patch reversal
I think that the below needs to be taken out of ap_vformatter in 1.3.26...
IIRC, it was a back-port of a 2.0 specific bug, regarding apr_psprintf().
This also gets rids of the bogusness of: It's not possible to
distinguish between an output which was truncated, and an output
which exactly filled the buffer which this patch caused.
Comments?
Index: src/ap/ap_snprintf.c
===
RCS file: /home/cvs/apache-1.3/src/ap/ap_snprintf.c,v
retrieving revision 1.51
diff -u -r1.51 ap_snprintf.c
--- src/ap/ap_snprintf.c14 Mar 2002 12:08:06 - 1.51
+++ src/ap/ap_snprintf.c6 Sep 2002 19:55:29 -
@@ -1158,10 +1158,6 @@
fmt++;
}
vbuff-curpos = sp;
-if (sp = bep) {
- if (flush_func(vbuff))
- return -1;
-}
return cc;
}
--
===
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 - T.Jefferson
Re: ap_vformatter (Apache 1.3) patch reversal
Jim Jagielski wrote: I think that the below needs to be taken out of ap_vformatter in 1.3.26... IIRC, it was a back-port of a 2.0 specific bug, regarding apr_psprintf(). This also gets rids of the bogusness of: It's not possible to distinguish between an output which was truncated, and an output which exactly filled the buffer which this patch caused. Comments? This implies, of course, that the real fix to 9932 is implemented, ala what was done with apr_vformatter and psprintf_flush. -- === 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 - T.Jefferson
Re: the listener thread didn't exit
This part, though, sounds like a new problem. Do you have a way to grab a stack trace of one of the stuck processes when this happens? Apparently this is somewhat reproducable, it happened again. Problem is too much to look at, 14 processes, 25 threads per and me hunting for a needle :-) . Guess I will have to try to tighten down on the runtime parameters and see if it will fail again. However, rooting through one of the 14 processes, I seen a trend in the traces though, many of them are stuck under alloca() under apr_poll. looks like I will need to talk with my libc folks and see if there are any known issues under there as I am running on a prerelease version of the OS. It feels like a locking issue inside alloca() at the moment. Dave
Re: Releasing 2.0.41
On Fri, Sep 06, 2002 at 12:20:48PM -0700, Greg Stein wrote: People usually have free time on the weekend, so the release is more easily done then. You can always do a 2.0.42 next week if you'd like. +1 Every time that somebody says hold off just a day, and again, and again, and before you know it, two weeks has passed without a release. Release numbers are cheap; time and volunteering it for a release is expensive. Let's let the RM decide when they'd like to release and work to that schedule. ++1!! [ and, preferably, work to that also means no cramming in fixes at the last minute, which invariably become bugs :-) ] +++1!!! :) -aaron
Re: Releasing 2.0.41
On Fri, 6 Sep 2002, Greg Stein wrote: | On Fri, Sep 06, 2002 at 02:12:10PM -0500, William A. Rowe, Jr. wrote: | ... | There are a few other little bugs that I'd like to fix so that 2.0.41 | holds most folks for a month or few. I have no objection if you simply | want to use an interim tag so we consume only the bug fixes. But it's | possibly easier just to hold off till Monday, if you wouldn't mind. | | People usually have free time on the weekend, so the release is more easily | done then. | | You can always do a 2.0.42 next week if you'd like. argh, we have to remember... Apache 2.0 is GA, not beta! /dale
Re: compatibility with C++ modules
hi, so could you possibly speak those unspeakable hacks you've made to apache to run c++ modules on hp? we're trying to get a c++ module linked into 2.0.39. any help would be appreciated. we can take this particular aspect of the discussion out of this forum, if you'd prefer, cheers andy Jeff Trawick wrote: At about the same time recently that I was doing horrible, uncommittable hacks to the build to get Apache 2.0 to support C++ modules on HP-UX, somebody wrote a PR against Apache 1.3 pointing out the same issue I encountered: If httpd is to properly support C++ modules, it may need to be linked with something other than the C compiler front-end, depending on the compiler and the platform. -- buy the buddha a beer tell him to move on to the next town -- Borland -- Enabling a new digital world where our customers have the freedom of choice to develop, deploy, and integrate applications across the enterprise and the Internet. http://www.borland.com This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately and permanently delete the original and any copy of any e-mail and any printout thereof.
Re: Releasing 2.0.41
On Fri, 6 Sep 2002, Dale Ghent wrote: On Fri, 6 Sep 2002, Greg Stein wrote: | On Fri, Sep 06, 2002 at 02:12:10PM -0500, William A. Rowe, Jr. wrote: | ... | There are a few other little bugs that I'd like to fix so that 2.0.41 | holds most folks for a month or few. I have no objection if you simply | want to use an interim tag so we consume only the bug fixes. But it's | possibly easier just to hold off till Monday, if you wouldn't mind. | | People usually have free time on the weekend, so the release is more easily | done then. | | You can always do a 2.0.42 next week if you'd like. argh, we have to remember... Apache 2.0 is GA, not beta! No, it is not. Apache 2.0.40 is GA. Apache 2.0 is a nonentity. 2.0.41 will start out as alpha, then be moved to beta, and finally to GA when and if we believe it is GA quality. Do NOT believe that just because 2.0.40 was GA, 2.0.41 will be too. We specifically said that wasn't true for 2.0. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: compatibility with C++ modules
At 11:27 AM 9/6/2002, Jeff Trawick wrote: Aaron Bannert [EMAIL PROTECTED] writes: On Fri, Sep 06, 2002 at 11:55:17AM -0400, Jeff Trawick wrote: Though we probably don't want to be in the business of pretending to support C++ modules in general, they certainly work with Apache on some platforms and we could at least make it simple for the user to specify the command to invoke to link httpd. This would default to the C compiler, but could be forced by the user to be g++ or aCC or whatever. ? --with-httpd-linker=g++ ? LD=g++ ./configure ... ?? definitely a more appropriate user interface, though it seems optimal not to bring any C++ rtl init/term logic into ab, htpasswd, and friends since it would only be necessary for httpd (I wondered why this didn't Just Work last time I tried it a few months ago, and stuck it on my todo list to fix it...) rules.mk is why it doesn't Just Work :) LINK = $(LIBTOOL) --mode=link $(COMPILE) $(LT_LDFLAGS) $(ALL_LDFLAGS) -o $@ Doesn't an option --c-plus-plus make more sense than a platform specific link foo option? Shouldn't we just extend libtool to deal with the platform specifics, g++ or whatnot, depending on what's required to support stl and other specifics? Bill
Re: Releasing 2.0.41
At 03:58 PM 9/6/2002, [EMAIL PROTECTED] wrote: On Fri, 6 Sep 2002, Dale Ghent wrote: On Fri, 6 Sep 2002, Greg Stein wrote: | You can always do a 2.0.42 next week if you'd like. argh, we have to remember... Apache 2.0 is GA, not beta! No, it is not. Apache 2.0.40 is GA. Apache 2.0 is a nonentity. 2.0.41 will start out as alpha, then be moved to beta, and finally to GA when and if we believe it is GA quality. Do NOT believe that just because 2.0.40 was GA, 2.0.41 will be too. We specifically said that wasn't true for 2.0. Exactly. The only reason folks may be puzzled by this change is that .40, .39 and .36 flew out the door in pretty much one pass. That's simply because the security bugs they addressed outweighed any comparison. If .41 is worse than .40 (or .36 for that matter) it shouldn't leave beta for GA. Bugs new to .40/.41 get fixed, then .42 will be released (alpha, then beta) and if it's *finally* better than .36 or .40 we can release it GA quality, with the seal of quality We consider Apache 2.0.x to be the best version of Apache available Thanks for reminding us of this, Ryan. Sander, care to tag today even, before the tree is shaken again ;-? Bill
Re: Releasing 2.0.41
While I appreciate the desire to not hold up releases, sometimes just saying we aim for a release at the end of the week or so on, with the RM having the final say, gives people who are lazy by nature (guess who I mean) a nudge to get off their behinds and do something (build/test/fix etc etc). I'm +1 for Sander being RM and +1 for him rolling when he sees fit, just giving another viewpoint :) david At 03:58 PM 9/6/2002, [EMAIL PROTECTED] wrote: On Fri, 6 Sep 2002, Dale Ghent wrote: On Fri, 6 Sep 2002, Greg Stein wrote: | You can always do a 2.0.42 next week if you'd like. argh, we have to remember... Apache 2.0 is GA, not beta! No, it is not. Apache 2.0.40 is GA. Apache 2.0 is a nonentity. 2.0.41 will start out as alpha, then be moved to beta, and finally to GA when and if we believe it is GA quality. Do NOT believe that just because 2.0.40 was GA, 2.0.41 will be too. We specifically said that wasn't true for 2.0. Exactly. The only reason folks may be puzzled by this change is that .40, .39 and .36 flew out the door in pretty much one pass. That's simply because the security bugs they addressed outweighed any comparison. If .41 is worse than .40 (or .36 for that matter) it shouldn't leave beta for GA. Bugs new to .40/.41 get fixed, then .42 will be released (alpha, then beta) and if it's *finally* better than .36 or .40 we can release it GA quality, with the seal of quality We consider Apache 2.0.x to be the best version of Apache available Thanks for reminding us of this, Ryan. Sander, care to tag today even, before the tree is shaken again ;-? Bill
[PATCH] compile mod_ssl in httpd 2.0 on Darwin 6.0
All, The following patch allows MacOSX/Darwin to find the SSL library. With this patch, the current CVS HEAD of httpd-2.0 compiles with mod_ssl enabled and passes all ssl tests in the perl-framework (except for ssl/proxy since I didn't have proxy enabled): Index: acinclude.m4 === RCS file: /home/cvspublic/httpd-2.0/acinclude.m4,v retrieving revision 1.130 diff -u -r1.130 acinclude.m4 --- acinclude.m419 Aug 2002 07:33:45 - 1.130 +++ acinclude.m46 Sep 2002 21:30:38 - @@ -461,7 +461,7 @@ ap_ssltk_libdir= for p in $ap_ssltk_base/lib /usr/local/openssl/lib \ /usr/local/ssl/lib /usr/local/lib /usr/lib /lib /usr/lib64; do -if test -f $p/libssl.a -o -f $p/libssl.so; then +if test -f $p/libssl.a -o -f $p/libssl.so -o -f $p/libssl.dylib; then ap_ssltk_libdir=$p break fi Same patch attached to prevent line-ending and word wrapping madness. I tested this on MacOSX 10.2 (Jaguar) and on a linux box. The reason to limit this to 10.2 is as follows: while Apple included the SSL library binary with previous versions of the OS, the headers were missing. Some people got results by snarfing headers from somewhere else, but mileage varied immensely. As of the 10.2 Apple developer tools installer, there is an optional install item that installs a BSD compatibility SDK. This has, among others, the OpenSSL headers needed to build mod_ssl. Enjoy, Sander 'one line patch' Temme -- Covalent Technologies [EMAIL PROTECTED] Engineering groupVoice: (415) 856 4214 303 Second Street #375 South Fax: (415) 856 4210 San Francisco CA 94107 PGP Fingerprint: 1E74 4E58 DFAC 2CF5 6A03 5531 AFB1 96AF B584 0AB1 === This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message === acinclude.m4.patch Description: Binary data
Re: Releasing 2.0.41
On Fri, Sep 06, 2002 at 10:28:40PM +0100, David Reid wrote: While I appreciate the desire to not hold up releases, sometimes just saying we aim for a release at the end of the week or so on, with the RM having the final say, gives people who are lazy by nature (guess who I mean) a nudge to get off their behinds and do something (build/test/fix etc etc). But that pile on approach destabilizes. If anything, the right approach is to simply tag quietly :-) The real answer is that people should always put stuff in, rather than wait. (of course, we know that isn't what happens...) Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: Releasing 2.0.41
On Fri, 6 Sep 2002, William A. Rowe, Jr. wrote: We consider Apache 2.0.x to be the best version of Apache available How about adding a box on http://httpd.apache.org/ that says something like 2.0.40 is our latest stable release There are no current beta releases available 2.0.41 is our latest alpha release maybe with a little explanation of the system below (that any alpha release might or might not be moved to stable or beta later). - ask -- ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
