Re: cvs commit: httpd-2.0/modules/ssl ...
At 02:46 PM 5/25/2003, Geoff Thorpe wrote: On May 24, 2003 09:38 am, William A. Rowe, Jr. wrote: Well, in the SSLC case, HAVE_SSL_SET_STATE was required because you can't even renegotiate without toggling the state. I tried a pretty simple hack, replacing the set state code (which on OpenSSL is simply a bit tweak into what should be opaque data) with the SSL_renegotate() function across toolkits (with the patch applied to 2_0_BRANCH). That didn't work, as several of the perl-framework ssl/ tests started failing. Considering that SSL_set_state a source patch on top of the SSLC toolkit, and most SSLC users work from binary distributions, this was never clean in the first place. Since ApacheSSL uses the SSL_renegotiate() function, and it's support in both toolkits, this is the right direction, I just missed something important (which I will revisit as I find some cycles again.) OK, I can't say anything of much usefulness about SSL-C as I have no experience with it. What I would suggest is that clean SSL-C support in Apache2 may be useful to many people, but there are none who benefit from it quite so much as RSA themselves. IIRC, it was from RSA that the original mod_ssl tweaks for SSL-C originated Excuse me? No... those have been the fruits of Doug MacEachern's, Madhu's and my own efforts. RSA has been helpful from a support perspective, but didn't actually port any code that *I* am aware of. - so it begs the question; are RSA involved in maintaining this code at all? It seems they should be doing as much as possible to avoid bitrot in the SSL-C hooks, and they'd be far better placed than anyone to make it happen (and test it)? The significant problem with mod_ssl's history is that the code reaches deep into the 'private', 'internals' of the library implementation. Ben Laurie, Madhu and I are refactoring the various bits that are too transparent into the guts of the library. It really should be the library's job to expose the appropriate interfaces... indeed they are in OpenSSL and SSL-C (somewhat differently in places.) But many of the appropriate 'methods' were introduced after they were first needed by mod_ssl, and that code was never refactored to approach the library cleanly. The problem from RSA's perspective is that they don't distribute mod_ssl, as far as I'm aware of, nor do they 'support' it. They support an SSL toolkit. Do whatever you will with it, and scream to them for negotiation bugs, or other toolkit operational or functional bugs. Covalent via Doug and myself, and HP via Madhu, have an interest in mod_ssl interoperating with the RSA toolkit, so all three of us have invested blood, sweat and tears to clean up some of the crufty stuff (occasionally introducing extra-crufty bits.) Hopefully others will grab their favorite toolkit and propose patches to extend the module. This isn't terribly compatible with the socket-based SSL approach, which is why Brad Nicholes had to deploy a different module for Netware. And though they are defined on Win32 (and supported on WinCE) the extended SSL WinSock foo is unimplemented (or generally not documented) across our Win32 supported platforms, so Win32 porters have gone the mod_ssl route. In any case, we won't 'HAVE' ENGINE_init if we don't inject ssl libs, so I don't have any problem moving those detection macros into the 'protected' reconfiguration. That still leaves me with the question of how we can test on a platform like solaris, where OpenSSL needs libraries like -lsocket just to perform a test compile of ENGINE_init(). Well this works inside the protected configuration for the reason that it pulls in the apr linker flags, whatever they may be (eg. -ldl -lsocket -lnsl [etc]). Ok, I see that now, and have committed the code to httpd-2.1 with all due credit to y'rself, thanks :-) But the better solution is to re-arrange the configuration order so the dependencies are already satisfied. No doubt, a project for another day (at least for my crazy schedule.) But we cannot quit testing for the SSL_set_state sort of functions (I don't know if you did or not) because I for one enjoy forcing SSL-C to do what it should have done in the first place :-) Please don't clobber function detection in your final patch, please! Well this certainly slipped through the cracks - apologies for my part, I don't have SSL-C so I was largely flying blind in that respect. In the future, please grep -r BOGUS_SYMBOL * before you submit this sort of patch, it makes it alot easier to see what's out there. Then it's not so confusing to search the archives for the discussion of why on earth the code is out there. Perhaps we should go ahead and use the pkgconfig if it exists, or fall back on our own autoconfig if it doesn't. Would that be a win? Maybe, but I think elegance dictates that the first priority would be to get the existing configuration steps ordered by dependency. The fact that apache-2
Re: Win32 .pdb symbol support [was: Time...] for 1.3.28
William A. Rowe, Jr. wrote: Ok, the .pdb changes are committed to apache-1.3 head, along with the updated .mak/.dep files. If someone else would mind checking out and validating the command line build (makefile.win), both Release and Debug, I'd be much obliged. Looks good to me. Allan
[VOTE]: Apache 2.0.46
Hi, I'd like to call a vote to release STRIKER_2_0_46_PRE2 as httpd-2.0.46. After the usual +1s, ;), I'll do the final TR. Thanks, Sander
Re: [VOTE]: Apache 2.0.46
--On Tuesday, May 27, 2003 9:07 PM +0200 Sander Striker [EMAIL PROTECTED] wrote: Hi, I'd like to call a vote to release STRIKER_2_0_46_PRE2 as httpd-2.0.46. After the usual +1s, ;), I'll do the final TR. httpd-test's perl-framework is failing on the expires test. Am looking into it now to see what is going on, but does anyone else see this? -- justin FAILED tests 2, 9, 13, 17, 21, 25, 29, 33, 37, 41, 45, 49 Failed 12/92 tests, 86.96% okay Failed Test Stat Wstat Total Fail Failed List of Failed --- modules/expires.t 92 12 13.04% 2 9 13 17 21 25 29 33 37 41 45 49
Re: cvs commit: httpd-2.0/modules/ssl ...
At 03:12 PM 5/27/2003, Geoff Thorpe wrote: But the better solution is to re-arrange the configuration order so the dependencies are already satisfied. No doubt, a project for another day (at least for my crazy schedule.) It's possiby a trivial change, and equally possibly a nightmare. BTW: Does this problem crop up with any other modules? Ie. do other modules have linker dependencies that are satisfied implicitly by apr? If so, they must surely face similar issues if they attempt to do any autoconf checks during configuration (and in which case, the issue of re-ordering the configuration system would solve a class of problems greater than just those of modssl). Hmmm... there are relatively few opportunities - things like db support in apr-util, zlib support in mod_deflate, etc. Actually continuing on that line of thinking, there's an orthogonal cleanup I could suggest, but one that might make later rearrangements less confusing; is it worth moving the SSL-specific M4 code out of the top-level and into modules/ssl/config.m4? This seems to be one of the ways in which the ssl module is (perhaps needlessly) unique in the way it is wired up to the rest of the tree. Just junk-food for thought. Well, that's one way. But it breaks our ability to wire up ab.c at the same time - my next set of effort was to activate ab.c in the 'correct' pattern we used for mod_ssl. Of course, laziness/carelessness played its part too, as you've observed. gulp If it's any consolation, I am now more painfully aware of SSL-C implications than I would have ever chosen to be. :-) This is another gleaming example of why two branch development has become effective for this project :-) No users were hurt in this progressive and cooperative development effort. Shoot down the bugs first, then review the unintended consequences later. I'll (mostly) hold my tongue - all I'll let slip is that I wrote ENGINE_init() and can imagine ways in which it could one-day be NOP'd out of existence. Now you have a reason not to :-) As long as we have parallel 0.9.7 and optional with 0.9.6 support for ENGINE, this will remain a pita. By the way, our result handling from the ENGINE_by_id() is bogus and disallows actually enabling any specific engine. I'm working on it once I've got all the build magic finished - but if you beat me to it tonight I owe you a couple of beers at the next AC event or wherever we next meet up :-) Of course, even if those possibilities did eventuate to be the Right Way forward for openssl, my current schedule puts them easily out of the reckoning for this decade at least... Amen to that, brother :-) Bill
mod_expires is broken was Re: [VOTE]: Apache 2.0.46
--On Tuesday, May 27, 2003 1:29 PM -0700 Justin Erenkrantz [EMAIL PROTECTED] wrote: httpd-test's perl-framework is failing on the expires test. Am looking into it now to see what is going on, but does anyone else see this? -- justin ExpiresDefault is busted. The offending line is mod_expires.c:531. t = apr_table_overlay(r-pool, notes-expfields, t); apr_table_overlay may create a new table, so the original pointer has to be updated as well. I'm trying to figure out what the proper fix is to this. The code makes it hard to figure out what t should be reset to in a clean manner. Using a ** might work, but that's lame. -- justin
guidance requested - how to get handler to work with GET in mod_dav_fs
I'd like to have handlers (from the http_request module, created by the Action and AddHandler directives) properly handle output sent from the mod_dav_fs module (with DEBUG_GET_HANDLER turned on.) For example, if mod_dav_fs handles a GET to a text/html file and I've added Action text/html /cgi-bin/footer.cgi, it should hand off the html document to the footer.cgi script for further processing. Is it the responsibility of the module responding to the GET to hand off to these handlers or should this be the default/core behavior of Apache? If not, can someone point me in the direction of how to hand off to a http_request handler? This functionality is critical for mod_dav backends. TIA!
Re: mod_expires is broken was Re: [VOTE]: Apache 2.0.46
Justin Erenkrantz wrote: --On Tuesday, May 27, 2003 1:29 PM -0700 Justin Erenkrantz [EMAIL PROTECTED] wrote: ExpiresDefault is busted. The offending line is mod_expires.c:531. t = apr_table_overlay(r-pool, notes-expfields, t); apr_table_overlay may create a new table always does, right? (or the doc is wrong :) ) It shouldn't matter whether the Expires and Cache-Control fields are added to headers_out or err_headers_out at this point in the filter chain, so shouldn't this work as a replacement? r-headers_out = apr_table_overlay(r-pool, notes-expfields, r-headers_out);
RE: mod_expires is broken was Re: [VOTE]: Apache 2.0.46
From: Justin Erenkrantz [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 27, 2003 11:19 PM --On Tuesday, May 27, 2003 1:29 PM -0700 Justin Erenkrantz [EMAIL PROTECTED] wrote: httpd-test's perl-framework is failing on the expires test. Am looking into it now to see what is going on, but does anyone else see this? -- justin ExpiresDefault is busted. The offending line is mod_expires.c:531. t = apr_table_overlay(r-pool, notes-expfields, t); apr_table_overlay may create a new table, so the original pointer has to be updated as well. I'm trying to figure out what the proper fix is to this. The code makes it hard to figure out what t should be reset to in a clean manner. Using a ** might work, but that's lame. -- justin Okay. Considering that reverting modules/metadata/mod_expires.c r1.39.2.2 doesn't lead to a regression with respect to 2.0.45, I'm considering that to be the best option. I'll drop it from the tag. Next release, which is hopefully a but quicker in succession to 2.0.46 than 2.0.46 is to 2.0.45, can have a proper fix. Sander
Re: [VOTE]: Apache 2.0.46
Sander Striker wrote: Hi, I'd like to call a vote to release STRIKER_2_0_46_PRE2 as httpd-2.0.46. +1 (assuming the mod_expires change reverted)
Re: [VOTE]: Apache 2.0.46
* Sander Striker wrote: Hi, I'd like to call a vote to release STRIKER_2_0_46_PRE2 as httpd-2.0.46. Please bump docs/manual/content-negotiation.* and docs/manual/env.* back to pre2. (prefer-language isn't in yet) nd -- +[++-][-]++.[++-]+++.--.+. .[-]---.+++[-]+.+.+.+++[-].---.+++[-] +..+[]+.+[-]+.+++[-]+.--..++ [---].+[+-].++..--.+++[-]+.
RE: [VOTE]: Apache 2.0.46
From: Andre Malo [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 28, 2003 2:24 AM * Sander Striker wrote: Hi, I'd like to call a vote to release STRIKER_2_0_46_PRE2 as httpd-2.0.46. Please bump docs/manual/content-negotiation.* and docs/manual/env.* back to pre2. (prefer-language isn't in yet) Will do. Thanks for the heads up. Prolly a stale viewcvs page I was looking at... Sander
Re: [VOTE]: Apache 2.0.46
--On Tuesday, May 27, 2003 9:07 PM +0200 Sander Striker [EMAIL PROTECTED] wrote: I'd like to call a vote to release STRIKER_2_0_46_PRE2 as httpd-2.0.46. +1 on _PRE3 (which is _PRE2 minus mod_expires brokenness) for Solaris, Darwin, and FreeBSD. -- justin
