Crash on replacing APR_BRIGADE_FOREACH
hi I have recently upgraded from Apache 2.0.53 to 2.2.3 .During upgrade I came to know that macro APR_BRIGADE_FOREACH has been deprecated so i replaced APR_BRIGADE_FOREACH(e, bb) with for(e = APR_BRIGADE_FIRST(bb); e != APR_BRIGADE_SENTINEL(bb); e = APR_BUCKET_NEXT(e)) but now on I am facing a crash in my code under this loop can any one help or give any suggestions on this Thanks/regards manmeet singh The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it.
Re: mod_python 3.3.0 beta available for testing
+1 Fedora Core 6 i386, Apache 2.2.3 (mpm-prefork), Python 2.4.4 +1 Fedora Core 5 i386, Apache 2.2.2 (mpm-prefork), Python 2.4.3 +1 Fedora Core 6 x86_64, Apache 2.2.3 (mpm-prefork), Python 2.4.4 The correct md5 file path is: http://people.apache.org/~jgallacher/mod_python/dist/mod_python-3.3.0b.tgz.md5 Regards, -- Clodoaldo Pinto Neto
httpd-proxy-scoreboard how to go on?
Hi, I would like to return the httpd-proxy-scoreboard to its first goal: A replacement of the scoreboard by pieces normal shared memory. To reach this the experiments of health_checker should be removed or changed to a provider of bytraffic/byrequest for mod_proxy_balancer and seen as an example how to use the slotmems. Any comments? Cheers Jean-Frederic
[EMAIL PROTECTED]: New: #40759: Unable to compile libapreq2]
Forwarded and closed since there is no apreq product in bugzilla, let infra know if you want one :) (this -lipv6api doesn't come from API so I presume it comes form apreq?) - Forwarded message from [EMAIL PROTECTED] - From: [EMAIL PROTECTED] Reply-To: Apache HTTPD Bugs Notification List bugs@httpd.apache.org To: bugs@httpd.apache.org Date: Sun, 15 Oct 2006 23:08:46 -0700 (PDT) Subject: New: #40759: Unable to compile libapreq2 http://issues.apache.org/bugzilla/show_bug.cgi?id=40759 Summary: Unable to compile libapreq2 Product: Apache httpd-2 Version: 2.3-HEAD Platform: DEC OS/Version: OSF/1 Status: NEW Severity: normal Priority: P2 Component: Other Modules AssignedTo: bugs@httpd.apache.org ReportedBy: [EMAIL PROTECTED] Hi, I tried compiling libapreq2 on DEC/OSF1. These are the steps I followed: 1. Downloaded the kit libapreq2-2.08 2. ./configure --with-apache2-apxs=/usr/opt/hpapache2/bin/apxs This is the error I get: cc -g -o .libs/test_cgi test_cgi.o -L/usr/opt/hpapache2/lib -L/build/src/suppor t/lib /usr/laxmi/libapreq2-2.08/library/.libs/libapreq2.so /usr/opt/hpapache2/li b/libaprutil-1.so -L/build/src/apache/httpd/srclib/apr-util/xml/expat/lib /usr/o pt/hpapache2/lib/libapr-1.so -L/build/src/directory/build_libs /usr/opt/hpapache 2/lib/libexpat.so /usr/internet/openldap/lib/libldap_r.so /usr/internet/openldap /lib/liblber.so -lipv6api -lssl -lcrypto -liconv -lrt -lm -lpthread -rpath /usr/ opt/hpapache2/lib:/usr/internet/openldap/lib ld: Can't locate file for: -lipv6api *** Exit 1 Stop. *** Exit 1 Stop. *** Exit 1 Stop. Any idea from where and why libipv6api.so is getting included? Thanks for your help Laxmi - End forwarded message -
Re: Creating a thread safe module and the problem of calling of 'CRYPTO_set_locking_callback' twice!
On Thu, 2006-12-07 at 18:41 +, Darryl Miles wrote: Maybe there is some (small) re-design of the Apache code needed? Agreed, something needs to be added. I'm saying there is no need to make it specific to OpenSSL. Serializing the initialization can be made generic such that these objectives are met: why not move this issue to libapr/libarp-util Through abstraction of OpenSSL (or whatever ssl implementation) all threading issues/race conditions etc. could be addressed and handled without any changes of mod_core (sure mod_ssl must be changed) After that mod_foo could use this abstraction instead of using OpenSSL. I know that this is a big peace of work and it doesn't solve the general lib_thread_save_intialisation_issue but it could be also of great use for any dev (beside httpd). regards klaus
Re: [EMAIL PROTECTED]: New: #40759: Unable to compile libapreq2]
Joe Orton wrote: Forwarded and closed since there is no apreq product in bugzilla, let infra know if you want one :) (this -lipv6api doesn't come from API so I presume it comes form apreq?) [8:32:02](ttypf)[EMAIL PROTECTED]: /home/pgollucci/dev/repos/asf/httpd/apreq/trunk 100 0 grep -R v6api * [nothing] I doubt its from apreq. Its probably part of the linker flags from earlier in the AMP stack. Did you compile everything with gcc ? perl, httpd, mod_perl etc ? -- Philip M. Gollucci ([EMAIL PROTECTED]) 323.219.4708 Consultant / http://p6m7g8.net/Resume/resume.shtml Senior Software Engineer - TicketMaster - http://ticketmaster.com 1024D/EC88A0BF 0DE5 C55C 6BF3 B235 2DAB B89E 1324 9B4F EC88 A0BF I never had a dream come true 'Til the day that I found you. Even though I pretend that I've moved on You'll always be my baby. I never found the words to say You're the one I think about each day And I know no matter where life takes me to A part of me will always be... A part of me will always be with you.
RE: IE7 wrecks language negotiation
Is there any way Apache could do the following? 1. Search for a match in the language and language-locale list the client provides 2. If no match was found above, strip off the locale and try again. 3. If there still isn't a match, use the server's default language. That way if the server's default is en but has content for en, de, and fr, and the client specified de-CH, de-AT, and fr-CA, de would be served instead of defaulting to en. That would seem to be more useful to the client. As of Apache 2.2.3, that scenario would end up serving en. Thoughts? , Josh. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joshua Slive Sent: Friday, December 08, 2006 2:00 PM To: dev@httpd.apache.org Subject: IE7 wrecks language negotiation Following up on a question on the users list, I found this blog entry: http://blogs.msdn.com/ie/archive/2006/10/17/accept-language-he ader-for-internet-explorer-7.aspx which says that IE7 now uses only language/locale pairs in the Accept-Language header. They follow this up with: If a given server is only interested in the user's language and not the locale, it can ignore the locale portion by simply truncating the code at the first dash. This tells server to ignore RFC2616 section 14.4 if they wish to work with IE7. The effect of this is that users who specify more than one acceptable language in IE7 aren't going to get the one they really prefer in many cases when working with HTTP/1.1 compliant servers (like apache httpd). (If only one language is selected, things should work okay because we added a work-around for this in 2.0. But it is impossible to work-around the problem with multiple languages and still follow the RFC.) It would be possible to add a BrowserMatch-settable variable to do the HTTP-breaking recommended by Microsoft, but I don't know if it is worth it. Joshua.
Re: [EMAIL PROTECTED]: New: #40759: Unable to compile libapreq2]
On Dec 11, 2006, at 11:33 AM, Philip M. Gollucci wrote: Joe Orton wrote: Forwarded and closed since there is no apreq product in bugzilla, let infra know if you want one :) (this -lipv6api doesn't come from API so I presume it comes form apreq?) [8:32:02](ttypf)[EMAIL PROTECTED]: /home/ pgollucci/dev/repos/asf/httpd/apreq/trunk 100 0 grep -R v6api * [nothing] I doubt its from apreq. Its probably part of the linker flags from earlier in the AMP stack. Did you compile everything with gcc ? perl, httpd, mod_perl etc ? is there a lipv6api file somewhere on the system , like in /usr/local/ lib or something? i kept running into an issue on freebsd where apreq kept looking in the apache2 dir ( /usr/local/lib/apache2 ) instead of /usr/local/lib everything would fail , because only a handful of apache specific libraries were in there i ended up solving it by doing some particularly nasty stuff regarding gcc, which works - but it messy as all hell i'd check to see if you have the lipv6api somewhere in /usr/local/lib or /usr/opt.i *think* its possible that libapreq is only looking in /usr/opt/hpapache2 also check the line above your error to see what exactly got linked correctly. its just a hunch... but it seems to be exactly like what was driving me crazy last weekend. // Jonathan Vanasco | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | FindMeOn.com - The cure for Multiple Web Personality Disorder | Web Identity Management and 3D Social Networking | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | RoadSound.com - Tools For Bands, Stuff For Fans | Collaborative Online Management And Syndication Tools | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Re: IE7 wrecks language negotiation
On 12/11/06, Fenlason, Josh [EMAIL PROTECTED] wrote: Is there any way Apache could do the following? 1. Search for a match in the language and language-locale list the client provides 2. If no match was found above, strip off the locale and try again. 3. If there still isn't a match, use the server's default language. That way if the server's default is en but has content for en, de, and fr, and the client specified de-CH, de-AT, and fr-CA, de would be served instead of defaulting to en. That would seem to be more useful to the client. As of Apache 2.2.3, that scenario would end up serving en. Hmmm, I haven't looked at the code in a while, but I was under the impression it did that already. Are you saying that the ordering of the fallback list (of languages with locale stripped of) is by the LanguagePriority directive rather than by the Accept-Language priority? If so, I agree that should be changed. Joshua.
RE: IE7 wrecks language negotiation
I swear that's the behavior I was seeing, but I must have had something messed up. I just tested to verify my complaint and it appears to be working the way I said I wanted it to. Not sure what I messed up, but I must have gotten confused when I was testing. Sorry for bringing up an issue that isn't an issue. I'll go hide in embarrassment. :) Thanks for the help. , Josh. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joshua Slive Sent: Monday, December 11, 2006 11:40 AM To: dev@httpd.apache.org Subject: Re: IE7 wrecks language negotiation On 12/11/06, Fenlason, Josh [EMAIL PROTECTED] wrote: Is there any way Apache could do the following? 1. Search for a match in the language and language-locale list the client provides 2. If no match was found above, strip off the locale and try again. 3. If there still isn't a match, use the server's default language. That way if the server's default is en but has content for en, de, and fr, and the client specified de-CH, de-AT, and fr-CA, de would be served instead of defaulting to en. That would seem to be more useful to the client. As of Apache 2.2.3, that scenario would end up serving en. Hmmm, I haven't looked at the code in a while, but I was under the impression it did that already. Are you saying that the ordering of the fallback list (of languages with locale stripped of) is by the LanguagePriority directive rather than by the Accept-Language priority? If so, I agree that should be changed. Joshua.
Re: IE7 wrecks language negotiation
On 12/11/06, Fenlason, Josh [EMAIL PROTECTED] wrote: I swear that's the behavior I was seeing, but I must have had something messed up. I just tested to verify my complaint and it appears to be working the way I said I wanted it to. Not sure what I messed up, but I must have gotten confused when I was testing. Sorry for bringing up an issue that isn't an issue. I'll go hide in embarrassment. :) Thanks for the help. Okay. And your thought points out that my whole rant was probably misplaced. It is true that IE7 is going backwards in spec-conformance, but it will only be a problem if people mix language tags with and without locale. In the case where the browser uses only tags with-locale, and the server uses either all tags with-locale or all tags without-locale, things should work right based on our previously-included work-arounds. So although IE7 will brake a bunch of reasonable configs, it probably isn't serious enough to warrant changing anything in apache. Joshua.
Re: Creating a thread safe module and the problem of calling of 'CRYPTO_set_locking_callback' twice!
William A. Rowe, Jr. wrote: Darryl Miles wrote: Your thinking is correct there is a problem. Those OpenSSL functions are not documented in my man page but exist in the library. Yes there is a read-test-write race window by using those APIs alone. Nope. This is set when the server process is running in single process, single thread mode, long before the server 'opens up' and spawns off it's worker threads. Understood on the single thread situation. But what about module initialization order guaranteed and possible future modules which may also use OpenSSL ? The goal is to ensure the CRYPTO_() init functions are called, and called exactly once before openssl first use only when openssl is being used. * mod_core (no mod_ssl, no mod_frank, no need do anything no openssl users) * mod_core + mod_ssl (no mod_frank) * mod_core + mod_frank (no mod_ssl) * mod_core + mod_ssl + mod_frank * mod_core + mod_frank + mod_ssl (opposite initialization order) There may not be worker threads and apache-http may not support dynamic runtime loading / unloading of modules (at this time) but its possible to deal with all those concerns cleanly. What I DO agree with is that these callbacks should be locked in much earlier than post_config. I'm happy to see these callbacks locked in at the time we register the module itself. Is the module registration order the same for a given canonical configuration (i.e. its not subject to httpd.conf config LoadModule directive ordering). Also can one module can ask the core what other modules are loaded and it can ask them if they too are users of OpenSSL. I.e. whatever system to address this problem is used would need to deal with the possible existence of a future mod_frank_v2 (that does not exist today but may do in the future) in a way that mod_ssl does not need to be recompiled or upgraded to know about mod_frank_v2 when the time comes to release mod_frank_v2. Darryl
Re: Wrong etag sent with mod_deflate
This is not a response to any post on this subject, but more of a comment. Here is a real world example of how we use deflate and etags with our cache. (Note this is very similar to mod_cache, but I do not know the inner workings of it as well). 1. Generate key from URI and ap_get_servername 2. open cached object. Is it Vary? no, goto step 5. 3. Is Vary. Generate new key. 4. Open cached object. 5. Check expiry time, exit if expired. 6. Load headers. 7. Call ap_meets_conditions (etags, IMS, etc.) If yes, return 304 (or whatever). 8. If not meets_conditions, serve from cache. So, multiple variants of the same object can have the same Etag, but still be different cached objects. This probably has no bearing on the current conversation, but perhaps I am not fully appreciating the core of the debate?? -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
PATCH #40075 - using ldap groups that contain DNs and usernames for AuthZ
Hey, I've addressed the last rounds of comments to my patch to mod_authnz_ldap. I haven't heard anything for a week, so I'm wondering, can someone please review these changes? Thanks, Johanna
Re: Creating a thread safe module and the problem of calling of 'CRYPTO_set_locking_callback' twice!
Klaus Wagner wrote: On Thu, 2006-12-07 at 18:41 +, Darryl Miles wrote: Maybe there is some (small) re-design of the Apache code needed? Agreed, something needs to be added. I'm saying there is no need to make it specific to OpenSSL. Serializing the initialization can be made generic such that these objectives are met: why not move this issue to libapr/libarp-util why not move this discussion to [EMAIL PROTECTED] There -is- an openssl wrapper now in apr (1.3-future release) that could fit the bill. This said, it won't be possible to accomplish the myriad features that mod_ssl exposes through a straightforward tls wrapper. We had one, mod_tls, that was dirt-simple-stupid and just-worked. It was also orphaned, people want more out of their crypto layer.
Re: PATCH #40075 - using ldap groups that contain DNs and usernames for AuthZ
On 12/11/2006 at 12:36 PM, in message [EMAIL PROTECTED], Johanna Bromberg Craig [EMAIL PROTECTED] wrote: Hey, I've addressed the last rounds of comments to my patch to mod_authnz_ldap. I haven't heard anything for a week, so I'm wondering, can someone please review these changes? Thanks, Johann Johanna, Sorry I haven't been able to get back to this quickly. I have been swamped with my day job lately. I will try to find some time to review the patch and hopefully have something to commit soon. Brad
