Handling multiple requests simultaneously in one thread
Hi, I am trying to design a custom Apache module that will allow me to efficiently stream data over HTTP to clients. Since many clients will be receiving the same streamed data, I would prefer to not tie up a thread per client, and instead have a single thread serve a group of clients. Is it possible to get a single thread in Apache to simultaneously handle multiple requests? Are there any modules you know about out there that do something like this? How do I hand over the request from one thread to the other without request_rec getting destroyed when the first thread continues with the next request? As you may have guessed by now I do not have a lot of experience developing Apache extensions, which is why the question is quite general. I would however be most grateful if someone could provide me some pointers/suggestions or let me know if what I am trying to do is impossible. Best regards, Chris - Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
Re: Pre-release tarballs: Apache httpd 1.3.41, 2.0.63 and 2.2.8
+1 on win32 for me if I could vote libaprutil is still set to x64 instead of win32 when compiling under 2008 but I take this will get fixed in the win32 src package multicast.c is still broken using vs 2008 with the latest platform SDK, vs 2005 with the older platform SDK works fine! (there is a patch for this... IIRC its also in apr trunk but it was laten when I was talking about this with wrowe I can't remember for certain) FWIW: BuildBin's installdir is still set to /apache2 instead of /apache22 not that will effect anything just something I noticed. The /machine not set warnings are still there aswel but again no problem here since it defaults to x86 modules compiled and working: - mod_perl - mod_macro - mod_fcgid - mod_ftp (compiles not tested) Jorge On Jan 11, 2008 5:33 AM, Paul Querna [EMAIL PROTECTED] wrote: Jim Jagielski wrote: Pre-release tarballs of Apache HTTP Server 1.3.41, 2.0.63 and 2.2.8 are available for download and test at: http://httpd.apache.org/dev/dist/ Their availability does not constitute an official release. However, please download and test. I will be calling for a release VOTE in the next 24-48 hours, at most. eos.apache.org and aurora.apache.org, the machines that host www.apache.org, and most TLPs, have both been upgraded to 2.2.8: http://www.apache.org/server-status They are also now running with the Event MPM, previously the Worker MPM was used. I used an APR and APR-Util snapshot, from their respective trunks, due to issues with mod_mbox performance, that have been fixed in apr-util trunk[1]. Both machines are Solaris 10/SPARC, and I ran into no major issues getting it all working. If you notice any issues with any apache.org sites, please let me know :-) Thanks, -Paul [1] - http://svn.apache.org/viewvc?view=revrevision=513046 -- ~Jorge
[Resolved]Re: Problem with directives
Thank you Joe for your answer!
I'm not sure port is the best one to use. Perhaps something more
specific to your module, such as MyLDAPPort, or even relying on the
ldaputil.c settings to set up that information for you.
You are right, I have changed it
It appears that someone's keyboard put in a few extra asterisks on
that. I see too many on a num_port line.
That's my new keyboard!! the're no asterisks!
I don't know if there is a best practice for choosing directives but it will
be intersting to have one
Concerning my problem I found the solution here:
http://threebit.net/tutorials/apache2_modules/tut2/tutorial2.html
Thak you for your help!!
On Jan 10, 2008 10:02 PM, Joe Lewis [EMAIL PROTECTED] wrote:
karim Bendadda wrote:
*Location /name_module
url http:\\10.114.20.8\myopenldap
port 389
baseDn someone
/Location*
I'm not sure port is the best one to use. Perhaps something more
specific to your module, such as MyLDAPPort, or even relying on the
ldaputil.c settings to set up that information for you.
*typedef struct mod_name{
apr_pool_t*mpool;
const char *url_LDAP;
** int num_port;
const char *base_dn;
}mod_name_conf;
It appears that someone's keyboard put in a few extra asterisks on
that. I see too many on a num_port line.
*static const command_rec **name**_cmds[] = {
AP_INIT_TAKE1(url**, ap_set_string_slot,
(void*)APR_OFFSETOF(mod_auth_conf, url_LDAP), OR_ALL,
url of openldap),
AP_INIT_TAKE1(port, ap_set_int_slot,
(void*)APR_OFFSETOF(mod_auth_conf, num_port), OR_ALL,
port of openldap),
AP_INIT_TAKE1(**baseDn**, ap_set_string_slot,
(void*)APR_OFFSETOF(mod_auth_conf, base_dn), OR_ALL,
base DN of LDAP),
{NULL}
};
One - I see WAY too many asterisks. There should be no asterisks in the
directive lines. Please remove them, and choose better directives.
Preface those directives with something more specific, please. For
example, if you LDAP module is a translate function that uses LDAP to
specify which file to retrieve, then you might call the directives
LDAPTranslateURL, LDAPTranslatePort, and LDAPTranslateBaseDN (this is
just a set of examples).
Joe
--
Karim
Re: [VOTE] Apache HTTP Server 1.3.41, 2.0.63 and 2.2.8
On Jan 11, 2008, at 9:09 AM, Jim Jagielski wrote: I am calling for a release VOTE on the above releases of Apache HTTP Server (1.3.41, 2.0.63 and 2.2.8). Pre-release tarballs of Apache HTTP Server 1.3.41, 2.0.63 and 2.2.8 are available for download and test at: http://httpd.apache.org/dev/dist/ Their availability does not constitute an official release. Voting will close in 72 hours (~9am, eastern, on Monday Jan. 14th) [+1] Apache HTTP Server 1.3.41 [+1] Apache HTTP Server 2.0.63 [+1] Apache HTTP Server 2.2.8
[VOTE] Apache HTTP Server 1.3.41, 2.0.63 and 2.2.8
I am calling for a release VOTE on the above releases of Apache HTTP Server (1.3.41, 2.0.63 and 2.2.8). Pre-release tarballs of Apache HTTP Server 1.3.41, 2.0.63 and 2.2.8 are available for download and test at: http://httpd.apache.org/dev/dist/ Their availability does not constitute an official release. Voting will close in 72 hours (~9am, eastern, on Monday Jan. 14th)
Re: [VOTE] Apache HTTP Server 1.3.41, 2.0.63 and 2.2.8
[] Apache HTTP Server 1.3.41 [] Apache HTTP Server 2.0.63 [+1] Apache HTTP Server 2.2.8 (win32 + mac) -- ~Jorge
Re: [VOTE] initial release of httpd-mod_ftp-0.9.1
Hi, Please fetch up the newly prepared httpd-mod_ftp-0.9.1.tar.gz, or the win32/netware/os2 suitable package httpd-mod_ftp-0.9.1-crlf.zip (and their md5/asc sigs), take it for a spin, and cast your choice There is one binding +1, no other votes. I count Guenter's +1 vote for removing STATUS-FTP, but not for a release. -1 for Linux -1 for NetWare I've just found a serious issue where empty dirs are not listened - thus you cant change to them. Happens on both Linux and NetWare, and I'm 100% sure that this worked before with an old version from last spring (2007-03-28) because at this time I did upload files to an empty 'incoming' folder. I didnt find the time yet to dig into fixing the issue; but I think we should first fix this and then together with the other changes in trunk tag 0.9.2. Guen.
Re: Pre-release tarballs: Apache httpd 1.3.41, 2.0.63 and 2.2.8
Jorge Schrauwen wrote: libaprutil is still set to x64 instead of win32 when compiling under 2008 but I take this will get fixed in the win32 src package No; you set it; that is to say that visual studio is bugged, and VC6 .dsw did not specify per-project dependencies, VS .sln migration makes foolish associations. This is even true when I introduce x64 targets to all projects, it has nothing to do with the source .dsw/.dsp files. You need to update these; there may be a separate package that offers .sln's at some point to fix VS bugs, haven't decided. (The src package is intended to be built from exported .mak files). multicast.c is still broken using vs 2008 with the latest platform SDK, vs 2005 with the older platform SDK works fine! (there is a patch for this... IIRC its also in apr trunk but it was laten when I was talking about this with wrowe I can't remember for certain) It's also on apr branches but not yet released; https://issues.apache.org/bugzilla/show_bug.cgi?id=40398 the patch applied to apr was the Cleaner and not Dirtier flavor. It will hit the next 1.2.x apr release, I'd presume there will be one sooner or later. FWIW: BuildBin's installdir is still set to /apache2 instead of /apache22 not that will effect anything just something I noticed. Yup - no impact, not likely to change. The /machine not set warnings are still there aswel but again no problem here since it defaults to x86 or defaults to x64 using that compiler/linker. Again, goofy win32 behaviors, and can't be fixed without x64 + win32 (x86) targets which would permit compilation using two-different targets. It was more than I wanted to mess with for this point bump, but will probably get back to that issue over the next several weeks.
Re: [VOTE] Apache HTTP Server 1.3.41, 2.0.63 and 2.2.8
+1 for Apache HTTP Server 1.3.41 on TPF -David
Re: [VOTE] Apache HTTP Server 1.3.41, 2.0.63 and 2.2.8
On 1/11/2008 at 7:09 AM, in message [EMAIL PROTECTED], Jim Jagielski [EMAIL PROTECTED] wrote: I am calling for a release VOTE on the above releases of Apache HTTP Server (1.3.41, 2.0.63 and 2.2.8). Pre-release tarballs of Apache HTTP Server 1.3.41, 2.0.63 and 2.2.8 are available for download and test at: http://httpd.apache.org/dev/dist/ Their availability does not constitute an official release. Voting will close in 72 hours (~9am, eastern, on Monday Jan. 14th) +1 1.3.41, 2.0.63, 2.2.8 NetWare
Re: [VOTE] initial release of httpd-mod_ftp-0.9.1
Hi, Please fetch up the newly prepared httpd-mod_ftp-0.9.1.tar.gz, or the win32/netware/os2 suitable package httpd-mod_ftp-0.9.1-crlf.zip (and their md5/asc sigs), take it for a spin, and cast your choice There is one binding +1, no other votes. I count Guenter's +1 vote for removing STATUS-FTP, but not for a release. oh, forgot about another small build issue on Linux: on my box, a SuSE 10.1, the httpd-prefork.conf wasnt found, and thus the 'make install' broke I did then insert a test for the file (not sure if this is the correct way, but at least I could then get past this issue, and finish the build): --- Makefile.apxs.orig Tue Dec 18 22:38:06 2007 +++ Makefile.apxs Fri Jan 11 20:25:16 2008 @@ -61,12 +61,14 @@ fi; \ done ; \ done - @awk -f $(ftp_srcdir)/build/addloadexample.awk \ - -v MODULE=ftp -v DSO=.so -v LIBPATH=$(rel_libexecdir) \ - -v EXAMPLECONF=$(rel_sysconfdir)/extra/ftpd.conf \ - $(httpd_conffile) $(httpd_conffile).new \ - ( mv $(httpd_conffile) $(httpd_conffile).bak \ - mv $(httpd_conffile).new $(httpd_conffile) ); + if test -e $(httpd_conffile); then \ + @awk -f $(ftp_srcdir)/build/addloadexample.awk \ + -v MODULE=ftp -v DSO=.so -v LIBPATH=$(rel_libexecdir) \ + -v EXAMPLECONF=$(rel_sysconfdir)/extra/ftpd.conf \ + $(httpd_conffile) $(httpd_conffile).new \ + ( mv $(httpd_conffile) $(httpd_conffile).bak \ + mv $(httpd_conffile).new $(httpd_conffile) ); \ + fi; svnroot=http://svn.apache.org/repos/asf/httpd manualdir=$(ftp_srcdir)/docs/manual Guen.
Hard to build httpd APR on OS X Leopard
Disclosure: My autotools expertise is not that great. In fact, since I've been in Ruby Java mostly the last few years, I may be missing something obvious at the ld or gcc level. This is all with a fresh 2.2.6 tarball downloaded earlier this week. This note to both [EMAIL PROTECTED] [EMAIL PROTECTED] because the problem seems to be in the crack between them. I got here because apr_global_mutex_create() was acting weird, so I wanted to step into it with the debugger. So I went to apr and did CFLAGS=-g ./configure make Oops... network_io/unix/sendrecv.c:967:2: error: #error APR has detected sendfile on your system, but nobody has written a network_io/unix/sendrecv.c:968:2: error: #error version of it for APR yet. To get past this, either write network_io/unix/sendrecv.c:969:2: error: #error apr_socket_sendfile or change APR_HAS_SENDFILE in apr.h to 0. Hmph. So I tried changing APR_HAS_SENDFILE in apr.h to 0 and make/ make install worked. But... I couldn't get httpd to build with my new APR living in /usr/ local/apr. I think this is because httpd's configure writes build/ config_vars.mk including this: LDFLAGS = -L/usr/lib -L/usr/local/apr/lib So, it's irrelevant how you go about building APR, you're gonna get the one that Leopard ships in /usr/lib (and hey, it's nice that Leopard ships with APR). I tried a few ./configure options but couldn't find one to force it to change the -L, so I eventually went and edited build/config_vars.mk, blecch. But then httpd wouldn't build, on the final -o httpd step I got Undefined symbols: _apr_socket_sendfile, referenced from: _ap_hack_apr_socket_sendfile in libmain.a(exports.o) _sendfile_it_all in libmain.a(core_filters.o) ld: symbol(s) not found Hokay... I suspect it's most likely that's I'm just ignorant of something obvious that Everybody Knows. If so, what is it? It does seem like it shouldn't be this hard. -Tim
Fwd: svn commit: r608508 - /httpd/httpd/trunk/modules/loggers/mod_log_forensic.c
-id = apr_psprintf(r-pool, %x:%lx:%x, getpid(), time(NULL), +id = apr_psprintf(r-pool, % APR_PID_T_FMT x:%lx:%x, getpid(), Stray 'x' in the new format string? No harm AFAICT. -- Eric Covener [EMAIL PROTECTED]
Re: svn commit: r611199 - in /httpd/httpd/trunk: CHANGES include/http_core.h modules/loggers/mod_logio.c
requires a minor bump? On Fri, 11 Jan 2008 15:07:57 - [EMAIL PROTECTED] wrote: Author: covener Date: Fri Jan 11 07:07:53 2008 New Revision: 611199 URL: http://svn.apache.org/viewvc?rev=611199view=rev Log: *) mod_logio: Provide optional function to allow modules to adjust the bytes_in count [Eric Covener] Practical example: alternate SSL implementation that lives beyond the filters (IOL)
Re: [VOTE] initial release of httpd-mod_ftp-0.9.1
Guenter Knauf wrote: I wouldn't mind a test for httpd_conffile = , I think your patch leaves a bit more of a chance for a subtle make install failure. huh? what you mean? In my case httpd_conffile wasnt empty but pointed to a non-existant file On my systems, that would be a bug, and I want install to croak. If you didn't want it updated at all, make httpd_conffile= would accomplish that without misleading those who do. Right? Bill
Re: Hard to build httpd APR on OS X Leopard
On Jan 11, 2008 3:20 PM, Tim Bray [EMAIL PROTECTED] wrote: I got here because apr_global_mutex_create() was acting weird, so I wanted to step into it with the debugger. So I went to apr and did CFLAGS=-g ./configure make you had already built httpd 2.2.6 at this point, and it was using the bundled apr? if so, I would have done 2.2.6 $ make distclean ./configure --enable-maintainer-mode --your-other-httpd-configure-opts make Oops... network_io/unix/sendrecv.c:967:2: error: #error APR has detected sendfile on your system, but nobody has written a network_io/unix/sendrecv.c:968:2: error: #error version of it for APR yet. To get past this, either write network_io/unix/sendrecv.c:969:2: error: #error apr_socket_sendfile or change APR_HAS_SENDFILE in apr.h to 0. Hmph. So I tried changing APR_HAS_SENDFILE in apr.h to 0 and make/ make install worked. fixed in apr-1.2.current, which will be bundled with upcoming httpd-2.2.8... -/- I've built some levels of httpd and apr on leopard, but I think it was always using explicit --with-apr= and --with-apr-util= flags to configure.
Re: Hard to build httpd APR on OS X Leopard
Henry Jen wrote: My guess is that you are not using the matching header files, perhaps you only fixed the -L option, but not the -I option for the header file. The other obvious question, did you also rebuild aprutil after you ./configure --with-apr=/usr/local/apr --prefix=/usr/local/apr and then httpd ./configure --with-apr=/usr/local/apr --with-apr-util=/usr/local/apr
Re: Fwd: svn commit: r608508 - /httpd/httpd/trunk/modules/loggers/mod_log_forensic.c
On Jan 11, 2008 5:04 PM, Ruediger Pluem [EMAIL PROTECTED] wrote: On 01/11/2008 10:32 PM, Eric Covener wrote: -id = apr_psprintf(r-pool, %x:%lx:%x, getpid(), time(NULL), +id = apr_psprintf(r-pool, % APR_PID_T_FMT x:%lx:%x, getpid(), Stray 'x' in the new format string? No harm AFAICT. On purpose. Before we had hex aoutput of the pid (don't know why) and there is no APR_PID_T_FMT_HEX- So I concat APR_PID_T_FMT and x to get a hex output I people thing that a hex output of a pid is stupid, well then lets remove the x, but the initial intention of the commit was to remove compiler warning no changing code. For APR_PID_T_FMT of 'd' (my vanilla 32-bit linux system) the 'x' ends up in the output as in: +26737x:4787e90e:0|GET / HTTP/1.0|User-Agent:Wget/1.10.2|Accept:*/*|Host:localhost|Connection:Keep-Alive -26737x:4787e90e:0 -- Eric Covener [EMAIL PROTECTED]
Re: [VOTE] initial release of httpd-mod_ftp-0.9.1
Guenter Knauf wrote: on my box, a SuSE 10.1, the httpd-prefork.conf wasnt found, and thus the 'make install' broke I did then insert a test for the file (not sure if this is the correct way, but at least I could then get past this issue, and finish the build): You could simply override make httpd_conffile=/filepath which is the preferred way. Long ago this should have become an independent apxs variable. I wouldn't mind a test for httpd_conffile = , I think your patch leaves a bit more of a chance for a subtle make install failure.
Re: [VOTE] initial release of httpd-mod_ftp-0.9.1
Hi, You could simply override make httpd_conffile=/filepath which is the preferred way. Long ago this should have become an independent apxs variable. ok. I wouldn't mind a test for httpd_conffile = , I think your patch leaves a bit more of a chance for a subtle make install failure. huh? what you mean? In my case httpd_conffile wasnt empty but pointed to a non-existant file Guen.
Re: Fwd: svn commit: r608508 - /httpd/httpd/trunk/modules/loggers/mod_log_forensic.c
On 01/11/2008 10:32 PM, Eric Covener wrote: -id = apr_psprintf(r-pool, %x:%lx:%x, getpid(), time(NULL), +id = apr_psprintf(r-pool, % APR_PID_T_FMT x:%lx:%x, getpid(), Stray 'x' in the new format string? No harm AFAICT. On purpose. Before we had hex aoutput of the pid (don't know why) and there is no APR_PID_T_FMT_HEX- So I concat APR_PID_T_FMT and x to get a hex output I people thing that a hex output of a pid is stupid, well then lets remove the x, but the initial intention of the commit was to remove compiler warning no changing code. Regards Rüdiger
Re: Hard to build httpd APR on OS X Leopard
Tim Bray wrote: Disclosure: My autotools expertise is not that great. In fact, since I've been in Ruby Java mostly the last few years, I may be missing something obvious at the ld or gcc level. This is all with a fresh 2.2.6 tarball downloaded earlier this week. This note to both [EMAIL PROTECTED] [EMAIL PROTECTED] because the problem seems to be in the crack between them. Hokay... I suspect it's most likely that's I'm just ignorant of something obvious that Everybody Knows. If so, what is it? It does seem like it shouldn't be this hard. -Tim As far as I know, this is all fixed in 2.2.8, which is currently being voted on to be released. Pre-release version is available from: http://httpd.apache.org/dev/dist/ The root cause is that Apple bundles a modified APR to support Sendfile on Leopard, but we didn't get the patches until after Leopard came out. APR 1.2.12, released on November 27, 2007, fixes these and a few other issues on Leopard: http://apr.apache.org/ httpd 2.2.8, is the first version of httpd to bundle the upgraded APR.
Re: svn commit: r611199 - in /httpd/httpd/trunk: CHANGES include/http_core.h modules/loggers/mod_logio.c
On 01/11/2008 07:04 PM, Takashi Sato wrote: requires a minor bump? Yep. On Fri, 11 Jan 2008 15:07:57 - [EMAIL PROTECTED] wrote: Author: covener Date: Fri Jan 11 07:07:53 2008 New Revision: 611199 URL: http://svn.apache.org/viewvc?rev=611199view=rev Log: *) mod_logio: Provide optional function to allow modules to adjust the bytes_in count [Eric Covener] Practical example: alternate SSL implementation that lives beyond the filters (IOL) Regards Rüdiger
Re: [VOTE] Apache HTTP Server 1.3.41, 2.0.63 and 2.2.8
On 01/11/2008 03:09 PM, Jim Jagielski wrote: I am calling for a release VOTE on the above releases of Apache HTTP Server (1.3.41, 2.0.63 and 2.2.8). Pre-release tarballs of Apache HTTP Server 1.3.41, 2.0.63 and 2.2.8 are available for download and test at: http://httpd.apache.org/dev/dist/ Their availability does not constitute an official release. Voting will close in 72 hours (~9am, eastern, on Monday Jan. 14th) Vote: [+1] httpd 1.3.41 [+1] httpd 2.0.63 [+1] httpd 2.2.8 Results: GPG signatures: OK md5 checksums : OK SuSE 10.2 32bit: 1.3.41: Failed Test Stat Wstat Total Fail Failed List of Failed --- t/apache/contentlength.t 206 30.00% 6 10 14 16 18 20 t/apache/headers.t 243 12.50% 3 6 9 t/apache/pr37166.t 41 25.00% 4 t/modules/include.t802 2.50% 29 44 (1 subtest UNEXPECTEDLY SUCCEEDED), 34 tests and 16 subtests skipped. Failed 4/68 test scripts, 94.12% okay. 12/1794 subtests failed, 99.33% okay. No regressions 2.0.63: worker: Failed Test Stat Wstat Total Fail Failed List of Failed --- t/modules/cgi.t 58 21 36.21% 14 16 32 34 36 38 40 42 44 46-49 51-58 (1 subtest UNEXPECTEDLY SUCCEEDED), 14 tests and 28 subtests skipped. Failed 1/80 test scripts, 98.75% okay. 21/2825 subtests failed, 99.26% okay. No regressions prefork: All tests successful (1 subtest UNEXPECTEDLY SUCCEEDED), 14 tests and 28 subtests skipped. Files=80, Tests=2825, 91 wallclock secs (45.97 cusr + 5.16 csys = 51.13 CPU) No regressions Litmus (WebDAV tests): - running `basic': 0. init.. pass 1. begin. pass 2. options... pass 3. put_get... pass 4. put_get_utf8_segment.. pass 5. mkcol_over_plain.. pass 6. delete pass 7. delete_null... pass 8. delete_fragment... pass 9. mkcol. pass 10. mkcol_again... pass 11. delete_coll... pass 12. mkcol_no_parent... pass 13. mkcol_with_body... pass 14. finish pass - summary for `basic': of 15 tests run: 15 passed, 0 failed. 100.0% - running `copymove': 0. init.. pass 1. begin. pass 2. copy_init. pass 3. copy_simple... pass 4. copy_overwrite pass 5. copy_nodestcoll... WARNING: COPY to non-existant collection '/litmus/litmus/nonesuch' gave '500 Internal Server Error' not 409 .. pass (with 1 warning) 6. copy_cleanup.. pass 7. copy_coll. pass 8. copy_shallow.. pass 9. move.. pass 10. move_coll. pass 11. move_cleanup.. pass 12. finish pass - summary for `copymove': of 13 tests run: 13 passed, 0 failed. 100.0% - 1 warning was issued. - running `props': 0. init.. pass 1. begin. pass 2. propfind_invalid.. pass 3. propfind_invalid2. pass 4. propfind_d0... pass 5. propinit.. pass 6. propset... pass 7. propget... pass 8. propextended.. pass 9. propmove.. pass 10. propget... pass 11. propdeletes... pass 12. propget... pass 13. propreplace... pass 14. propget... pass 15. propnullns pass 16. propget... pass 17. prophighunicode... pass 18. propget... pass 19. propremoveset. pass 20. propget... pass 21. propsetremove. pass 22. propget... pass 23. propvalnspace. pass 24. propwformed... pass 25. propinit.. pass 26. propmanyns pass 27. propget... pass 28. propcleanup... pass 29. finish pass - summary for `props': of 30 tests run: 30 passed, 0 failed. 100.0% - running `locks': 0. init.. pass 1. begin. pass 2. options... pass 3. precond... pass 4. init_locks pass 5. put... pass 6. lock_excl. pass 7. discover.. pass 8. refresh... pass 9. notowner_modify... pass 10. notowner_lock. pass 11. owner_modify.. pass 12. notowner_modify... pass 13. notowner_lock. pass 14. copy.. pass 15. cond_put.. FAIL (PUT conditional on lock and etag failed: 412 Precondition Failed) 16. fail_cond_put. pass 17. cond_put_with_not. pass 18. cond_put_corrupt_token WARNING: PUT failed with 400 not 423 .. pass (with 1 warning) 19. complex_cond_put.. FAIL (PUT with complex conditional failed: 412 Precondition
Re: Fwd: svn commit: r608508 - /httpd/httpd/trunk/modules/loggers/mod_log_forensic.c
On 01/11/2008 11:13 PM, Eric Covener wrote: On Jan 11, 2008 5:04 PM, Ruediger Pluem [EMAIL PROTECTED] wrote: On 01/11/2008 10:32 PM, Eric Covener wrote: -id = apr_psprintf(r-pool, %x:%lx:%x, getpid(), time(NULL), +id = apr_psprintf(r-pool, % APR_PID_T_FMT x:%lx:%x, getpid(), Stray 'x' in the new format string? No harm AFAICT. On purpose. Before we had hex aoutput of the pid (don't know why) and there is no APR_PID_T_FMT_HEX- So I concat APR_PID_T_FMT and x to get a hex output I people thing that a hex output of a pid is stupid, well then lets remove the x, but the initial intention of the commit was to remove compiler warning no changing code. For APR_PID_T_FMT of 'd' (my vanilla 32-bit linux system) the 'x' ends up in the output as in: +26737x:4787e90e:0|GET / HTTP/1.0|User-Agent:Wget/1.10.2|Accept:*/*|Host:localhost|Connection:Keep-Alive -26737x:4787e90e:0 Ok, you convinced me in rereading the printf man page and now I agree that this does not work as expected :-). As I see no sense in hex pids anyway (for sure there is a reason why there is no APR_PID_T_FMT_HEX :-), lets just drop the x. Regards Rüdiger
Re: [VOTE] Apache HTTP Server 1.3.41, 2.0.63 and 2.2.8
Jim Jagielski wrote: I am calling for a release VOTE on the above releases of Apache HTTP Server (1.3.41, 2.0.63 and 2.2.8). Pre-release tarballs of Apache HTTP Server 1.3.41, 2.0.63 and 2.2.8 are available for download and test at: http://httpd.apache.org/dev/dist/ Their availability does not constitute an official release. Voting will close in 72 hours (~9am, eastern, on Monday Jan. 14th) [ ] 1.3.41 [ ] 2.0.63 [+1] 2.2.8 Looks good on apache.org (Solaris 10) and on some of mine freebsd machines. -Paul
Re: Pre-release tarballs: Apache httpd 1.3.41, 2.0.63 and 2.2.8
On 1/11/08, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Jorge Schrauwen wrote: libaprutil is still set to x64 instead of win32 when compiling under 2008 but I take this will get fixed in the win32 src package No; you set it; that is to say that visual studio is bugged, and VC6 .dsw did not specify per-project dependencies, VS .sln migration makes foolish associations. This is even true when I introduce x64 targets to all projects, it has nothing to do with the source .dsw/.dsp files. You need to update these; there may be a separate package that offers .sln's at some point to fix VS bugs, haven't decided. (The src package is intended to be built from exported .mak files). multicast.c is still broken using vs 2008 with the latest platform SDK, vs 2005 with the older platform SDK works fine! (there is a patch for this... IIRC its also in apr trunk but it was laten when I was talking about this with wrowe I can't remember for certain) It's also on apr branches but not yet released; https://issues.apache.org/bugzilla/show_bug.cgi?id=40398 the patch applied to apr was the Cleaner and not Dirtier flavor. It will hit the next 1.2.x apr release, I'd presume there will be one sooner or later. FWIW: BuildBin's installdir is still set to /apache2 instead of /apache22 not that will effect anything just something I noticed. Yup - no impact, not likely to change. The /machine not set warnings are still there aswel but again no problem here since it defaults to x86 or defaults to x64 using that compiler/linker. Again, goofy win32 behaviors, and can't be fixed without x64 + win32 (x86) targets which would permit compilation using two-different targets. It was more than I wanted to mess with for this point bump, but will probably get back to that issue over the next several weeks. I'd be willing to generate and package vs 2008 sln and fix the apr-util goofyness. Say if solution files are created... do we want different packages for 2005, 2008,...? 2008 is said to be compatible with 2005 but opening a 2005 sln in 2008 it still randomly changes settings and such. Say if I create such a extended package based on the office 2.2.8 win32 src do you think that could be useful? I can always place it on my own website for interested people but I suspect it won't get much attention there and won't be worth the hassle. -- ~Jorge
Re: svn commit: r611216 - in /httpd/httpd/trunk/modules/ssl: ssl_engine_init.c ssl_engine_kernel.c ssl_engine_vars.c ssl_private.h
On 01/11/2008 05:04 PM, [EMAIL PROTECTED] wrote:
Author: fuankg
Date: Fri Jan 11 08:04:26 2008
New Revision: 611216
URL: http://svn.apache.org/viewvc?rev=611216view=rev
Log:
Restructured server name indication support (PR 34607);
added missing client cert support.
Submitted by: Kaspar Brand asfbugz velox.ch
Modified:
httpd/httpd/trunk/modules/ssl/ssl_engine_init.c
httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c
httpd/httpd/trunk/modules/ssl/ssl_engine_vars.c
httpd/httpd/trunk/modules/ssl/ssl_private.h
Modified: httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c?rev=611216r1=611215r2=611216view=diff
==
--- httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c (original)
+++ httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c Fri Jan 11 08:04:26 2008
@@ -1909,3 +1913,118 @@
+static int ssl_find_vhost(void *servername, conn_rec *c, server_rec *s)
+{
+SSLSrvConfigRec *sc;
+SSL *ssl;
+BOOL found = FALSE;
+apr_array_header_t *names;
+int i;
+
+/* check ServerName */
+if (!strcasecmp(servername, s-server_hostname)) {
+found = TRUE;
+}
+
+/*
+ * if not matched yet, check ServerAlias entries
+ * (adapted from vhost.c:matches_aliases())
+ */
+if (!found) {
+names = s-names;
+if (names) {
+char **name = (char **)names-elts;
+for (i = 0; i names-nelts; ++i) {
+if (!name[i])
+continue;
+if (!strcasecmp(servername, name[i])) {
+found = TRUE;
+break;
+}
+}
+}
+}
+
+/* if still no match, check ServerAlias entries with wildcards */
+if (!found) {
+names = s-wild_names;
+if (names) {
+char **name = (char **)names-elts;
+for (i = 0; i names-nelts; ++i) {
+if (!name[i])
+continue;
+if (!ap_strcasecmp_match(servername, name[i])) {
+found = TRUE;
+break;
+}
+}
+}
+}
+
+/* set SSL_CTX (if matched) */
+if (found (ssl = ((SSLConnRec *)myConnConfig(c))-ssl)
+(sc = mySrvConfig(s))) {
+SSL_set_SSL_CTX(ssl, sc-server-ssl_ctx);
+/*
+ * SSL_set_SSL_CTX() only deals with the server cert,
+ * so we need to duplicate a few additional settings
+ * from the ctx by hand
+ */
+SSL_set_options(ssl, SSL_CTX_get_options(ssl-ctx));
Sorry for being confused, but shouldn't this be sc-server-ssl_ctx
instead of ssl-ctx?
+if ((SSL_get_verify_mode(ssl) == SSL_VERIFY_NONE) ||
+(SSL_num_renegotiations(ssl) == 0)) {
+ /*
+* Only initialize the verification settings from the ctx
+* if they are not yet set, or if we're called when a new
+* SSL connection is set up (num_renegotiations == 0).
+* Otherwise, we would possibly reset a per-directory
+* configuration which was put into effect by ssl_hook_Access.
+*/
+SSL_set_verify(ssl, SSL_CTX_get_verify_mode(ssl-ctx),
+ SSL_CTX_get_verify_callback(ssl-ctx));
Same question as above.
+}
+
+return 1;
+}
+
+return 0;
+}
+#endif
Regards
Rüdiger
