Re: 2.0.49 : mod_ldap = util_ldap.c ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I've tried get a stacktrace from the core but was unsuccessful, adb reports no_entry. The machine is a hppa2.0w ( 64 bit ), the application is 32 bit, which is not a problem, but I assume supplying a 32 bit binary and a 64 bit core to adb would cause strange behaviour, no ? Anyway, I have no more time to spend on this problem so I'll leave the caching disabled and try to increase the performance of the openldap server. I'll try again with the next release. Thanks again for all your responses ! Peter. Graham Leggett wrote: | Peter Van Biesen wrote: | | I created the directory ldapCache under the serverroot and | restarted the server. The file sharedCacheFile was created, but | with owner root, while the server itself runs under sysadm user ( | but apachectl is run by root, to be able to bind to port 80 ) . | Anyways, the httpd child processes all core : | | | Is this due to the permission problem ? Is there a way to avoid | this ? Or do I have to initialize the sharedCacheFile in some | special way ? | | | Any core is a software problem, not a setup one - can you provide a | backtrace on the core? | | Regards, | Graham | -- | | - -- Peter Van Biesen Adj. Sysadmin V.F.S.I.P.H. tel: +32 (0) 2 225 85 70 fax: +32 (0) 2 225 85 88 e-mail: [EMAIL PROTECTED] PGP: http://www.vlafo.be/pgpkeys/[EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAjikQHtEPd3S05zgRArPaAJ9lxBQqR940byzmTB/XsxEg23ujhQCeMd/Q mGq5CYpJclLzQq2CkkXBb8A= =faBD -END PGP SIGNATURE-
Re: [PATCH] mod_log_forensic, BaseAddr.ref
this patch fixes compilation on Win32 for me since older SDK has no unistd.h; and btw. I was also able to compile without unistd.h for NetWare target without warnings about missing prototypes, so maybe its obsolete at all archived as BZ #28572: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=28572 to avoid another warning an entry in BaseAddr.ref would be fine too and btw. mod_version also has no entry yet; it should either get one, or the linker option should be removed to kill the warming. archived as BZ #28575: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=28575 Guenter.
Re: [PATCH] mod_log_forensic, BaseAddr.ref
Arghh! sorry, hit the wrong button -- this should go deleted instead of sended! this patch fixes compilation on Win32 for me since older SDK has no unistd.h; and btw. I was also able to compile without unistd.h for NetWare target without warnings about missing prototypes, so maybe its obsolete at all archived as BZ #28572: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=28572 to avoid another warning an entry in BaseAddr.ref would be fine too and btw. mod_version also has no entry yet; it should either get one, or the linker option should be removed to kill the warming. archived as BZ #28575: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=28575 Guenter.
mod_zeroconf code donation
All, Following a certain amount of personal upheaval, I now find myself in somewhat calmer waters, and would like to restate my interest in donating mod_zeroconf to the Apache community. To spike your memory, I'm including the original mail I sent to this list in February, below. During the first discussion, I heard sentiments pointing both in the direction of making the module a subproject, as I propose below, and dropping it into modules/experimental. I'm open to both, and we can always decide on this during incubation. Please let me know what you think, and do we have any takers for PPMC? Thanks, Sander From: Sander Temme [EMAIL PROTECTED] Date: Fri, 13 Feb 2004 10:40:01 -0700 To: [EMAIL PROTECTED] Subject: Proposal: donating mod_zeroconf -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello httpd [EMAIL PROTECTED] folks, The following is very similar to a message I sent to [EMAIL PROTECTED] a week ago. They requested that I bring the subject up on this mailinglist as well to encourage public discussion of the proposal, so here we go: At Apachecon 2003, I gave a presentation on mod_zeroconf[1]. This is a module I'm working on that allows Apache 2.0 to publish its virtual hosts on a Zero Configuration[2] network, an IETF standard perhaps better known as Rendezvous[3]. Mod_zeroconf brings this technology to Apache on other platforms than MacOSX. I will hold another presentation on mod_zeroconf at CodeCon 2004, later this month in San Francisco[4]. I would like to explore the possibility that the httpd project to adopt mod_zeroconf as a subproject. After incubation, the module would find a home under the 'modules' page at the httpd project, among mod_python, mod_auth_ldap et al. The code is already Apache licensed (Licenze 2.0, no less!). There are no third-party IP problems that I know of: the module is my original work. I have a CLA on file with the ASF and am fully prepared to release copyright of the module to the foundation. I would like to volunteer as maintainer of the module under the ASF umbrella. This is not a condition for donation, but I'd like to stay involved in the development of mod_zeroconf. The module is presently unfinished: demoable but well short of ready for prime time. The code that I presented at Apachecon is available at [1] under the downloads link. Last week, I dropped in a fresh snapshot labeled mod_zeroconf-0.2. I'll do some more work on the module in the next couple of weeks, and will have another pre-release at CodeCon. There is no public CVS repository at this time, but I'll be happy to provide snapshots for review. The ASF is my first and preferred home for the module. Other options would include stashing it at Sourceforge, or get a domain registered and run the project on my own infrastructure. However, I like the fact that the ASF forms a cohesive community and would provide a context for the code. Having the httpd project adopt mod_zeroconf would mean more visibility for the module, more eyes on the code and a cool new optional feature for Apache 2.0. This is not a take-it-or-leave-it offer: I'm open to any suggestions and appreciate your feedback. Thank your for your attention, Sander [1] http://www.temme.net/sander/mod_zeroconf/ [2] http://www.zeroconf.org/ [3] http://www.apple.com/macosx/features/rendezvous/ [4] http://www.codecon.org/2004/program.html#mod_zeroconf -- [EMAIL PROTECTED] http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF smime.p7s Description: S/MIME cryptographic signature
Re: cvs commit: httpd-2.0 - Imported sources
On Tue, 27 Apr 2004 [EMAIL PROTECTED] wrote: clar2004/04/27 11:22:27 Log: no message Status: Vendor Tag: avendor Release Tags: arelease C httpd-2.0/VERSIONING C httpd-2.0/config.layout C httpd-2.0/ROADMAP C httpd-2.0/LAYOUT C httpd-2.0/LICENSE C httpd-2.0/.gdbinit C httpd-2.0/NOTICE ... 2064 conflicts created by this import. Use the following command to help the merge: Um, what just happened? :-)
Re: cvs commit: httpd-2.0 - Imported sources
Duh? What is that? I was just playing with Cervisia and gvcs setting up my connection to cvs and updating my files. Did I screw up something? JJ [EMAIL PROTECTED] 4/27/2004 11:28:25 AM On Tue, 27 Apr 2004 [EMAIL PROTECTED] wrote: clar 2004/04/27 11:22:27 Log: no message Status: Vendor Tag: avendor Release Tags: arelease C httpd-2.0/VERSIONING C httpd-2.0/config.layout C httpd-2.0/ROADMAP C httpd-2.0/LAYOUT C httpd-2.0/LICENSE C httpd-2.0/.gdbinit C httpd-2.0/NOTICE ... 2064 conflicts created by this import. Use the following command to help the merge:Um, what just happened? :-)
Re: cvs commit: httpd-2.0 - Imported sources
On Tue, 27 Apr 2004, Jean-Jacques Clar wrote: I was just playing with Cervisia and gvcs setting up my connection to cvs and updating my files. Somehow an 'avendor' branch got added on all files in the httpd-2.0 repository. I dunno what Cervisia and gvcs did, but it wasn't what you wanted. :) I'll see if I can find a way to back out the import. --Cliff
NOTICE: httpd-2.0 repository currently unavailable
Just so you all know, I'm taking the httpd-2.0 repository offline while I work on it. It's chmodded to 000 right now, so don't be surprised when you can't get at it. :)
Re: NOTICE: httpd-2.0 repository currently unavailable
FYI. -- Forwarded message -- Date: 27 Apr 2004 22:09:18 - From: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: cvs commit: httpd-2.0 STATUS jwoolley2004/04/27 15:09:18 Modified:.STATUS Log: repository is opened back up. it turns out it's basically impossible to delete a branch in CVS without manual intervention -- which i don't want to do. we'll do it when we convert to SVN, at which point it will be trivial. in the meanwhile, it's not hurting anything to leave it as-is. here's a note to remind us to make the change when we convert. so, hey guys. how 'bout that SVN? :) Revision ChangesPath 1.777 +5 -1 httpd-2.0/STATUS Index: STATUS === RCS file: /home/cvs/httpd-2.0/STATUS,v retrieving revision 1.776 retrieving revision 1.777 diff -u -d -u -r1.776 -r1.777 --- STATUS4 Jan 2004 15:08:00 - 1.776 +++ STATUS27 Apr 2004 22:09:17 - 1.777 @@ -23,6 +23,10 @@ CURRENT RELEASE NOTES: +* When the CVS-SVN is done, there's a bogus avendor branch that should be + removed from most files. The branch was created 4/27/2004. It's safest + (and easiest) for now just to leave it in there; the MAIN branch and the + APACHE_2_0_BRANCH are untouched and unharmed. --jwoolley RELEASE SHOWSTOPPERS:
Re: [PATCH] RFC: Allow modification/deletion of specific headers in apr_table_t
Brian, If you ask me, I can write the new functions (i.e. the apr_table_do - type functions you described) and submit a patch for review. Let me know ... -sumeet Sumeet Singh wrote: Brian Pane wrote: On Apr 21, 2004, at 9:11 AM, Sumeet Singh wrote: Hi, In my use-case I am dealing with multiple headers with the same key (e.g. Cookie), and need to modify or remove a specific header based on its key and value (e.g. remove a certain cookie header while leaving the rest in). There is no api in apr_tables that would allow me to remove a given header instance. apr_table_unset will remove all cookies. And I can't have my code remove a header from the apr_array_table_t array because that will render the internal hash index incorrect. Secondly, eventhough I can modify the value of a specific header by iterating over the apr_array_header_t, that would be inefficient because I wouldn't be able to use the internal index_first and index_last values. Therefore I have written three functions (patch files attached) and am hoping that the powers-that-be will be willing to review and roll them into the APR codeline. 1) apr_table_set_one (apr_table_t *t, const char *key, const char *oldVal, const char *newVal) replaces value of header key and value oldVal with value newVal. If oldVal is null, then the first occurance of the header is replaces (this is an optimization for situations where we know that only one header exists and don't care about its current value). If the header is not found, then it behaves like apr_table_add. I finally got a chance to read through the patch. The code makes sense, but I have a question: will apr_table_set_one and apr_table_unset_one provide all the functionality you need? Using Cookie and Set-Cookie headers as an example, it seems like an exact match on the oldVal wouldn't be sufficient. If your response headers include something like this: Content-Type; text/html Set-Cookie: userID=1; max-age=86400; domain=.example.com Cache-Control: private Set-Cookie: sessionID=54321; max-age=1800; domain=.example.com and you want to change or remove the userID cookie, it's a lot easier to do a prefix match on userID= than on the entire value of that table entry. (If that table entry was set by some other module, we may not know what the full value of that entry is.) That's a good point. In the general case, an application might need to: 1. iterate through all the elements in a table that match a given key, 2. selectively modify the value of one or more of the matching elements, or delete one or more of the matching elements, 3. and optionally stop iterating based on some application-defined criteria. Agreed. This sounds a lot like apr_table_do, except that apr_table_do doesn't allow modification of the table elements. If there were a variant of apr_table_do that allowed modification of the value (but not the key) of visited elements, and the deletion of visited elements, would that work for your application? Yes that should suffice. Thanks. -sumeet Brian
Re: [PATCH] RFC: Allow modification/deletion of specific headers in apr_table_t
Sumeet Singh wrote: Brian, If you ask me, I can write the new functions (i.e. the apr_table_do - type functions you described) and submit a patch for review. Let me know I have often wanted an apr_table_do-esque interface that allowed for modification of table entries as suggested, so that sounds good to me. --Geoff
