Re: [A-T patch] give a hint how to raise the timeout
On Mar 4, 2004, at 4:15 PM, Stas Bekman wrote: The patch below attempts to give users an idea to try before they rush to report a bug. For example: waiting 120 seconds for server to start: not ok giving up after 121 secs. If you think that your system is slow or overloaded try again with a longer timeout value. For example: % APACHE_TEST_STARTUP_TIMEOUT=420 make test or: % /home/stas/apache.org/mp2-cvs/Apache-Test/t/TEST -startup_timeout=420 server failed to start! (please examine t/logs/error_log) Well, to be compliant with the output that Test::Harness expects, you should precede each line that's intended for the user rather than for Test Harness with # . since most likely they run 'make test' I put that option first. How does that sound? It'd be better if you could tell what they were running. It might have been ./Build test (and will be more and more, as soon as Apache::TestMB is done). Regards, David
Re: [A-T patch] give a hint how to raise the timeout
David Wheeler wrote: On Mar 4, 2004, at 4:15 PM, Stas Bekman wrote: The patch below attempts to give users an idea to try before they rush to report a bug. For example: waiting 120 seconds for server to start: not ok giving up after 121 secs. If you think that your system is slow or overloaded try again with a longer timeout value. For example: % APACHE_TEST_STARTUP_TIMEOUT=420 make test or: % /home/stas/apache.org/mp2-cvs/Apache-Test/t/TEST -startup_timeout=420 server failed to start! (please examine t/logs/error_log) Well, to be compliant with the output that Test::Harness expects, you should precede each line that's intended for the user rather than for Test Harness with # . Not in this case. T-H wasn't called yet. It gets called only after server successfully starts. since most likely they run 'make test' I put that option first. How does that sound? It'd be better if you could tell what they were running. It might have been ./Build test (and will be more and more, as soon as Apache::TestMB is done). If you they did: % make test but you'd suggest to run: % ./Build test not only it'll confuse the user, who aren't aware of Build or t/TEST (in caes of Makemaker) existance, but it also won't do what you wanted the user to do. For example 'make test' in mp2 runs several tests suites and also ensures to print a bug report banner. t/TEST will run only one test suite and won't print the banner (unless the flag -bugreport flag will be passed). __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [A-T patch] give a hint how to raise the timeout
On Mar 4, 2004, at 5:09 PM, Stas Bekman wrote: Not in this case. T-H wasn't called yet. It gets called only after server successfully starts. Ah, right, okay. If you they did: % make test but you'd suggest to run: % ./Build test not only it'll confuse the user, who aren't aware of Build or t/TEST (in caes of Makemaker) existance, but it also won't do what you wanted the user to do. For example 'make test' in mp2 runs several tests suites and also ensures to print a bug report banner. t/TEST will run only one test suite and won't print the banner (unless the flag -bugreport flag will be passed). All I'm saying is that it could be confusing if they ran './build test' and you're asking them to run 'make test'. But FWIW, I see this type of problem all the time. For example, CPAN and CPANPLUS will prompt you to run 'make install UNINST=1' when they notice older versions of a module you're installing, even if the module is using Module::Build and needs to run './Build install uninst=1'. I don't know of a simple answer to this problem, but using 'make install' is probably the simplest thing to do for the time being. Regards, David
Re: [A-T patch] give a hint how to raise the timeout
David Wheeler wrote: On Mar 4, 2004, at 5:09 PM, Stas Bekman wrote: Not in this case. T-H wasn't called yet. It gets called only after server successfully starts. Ah, right, okay. If you they did: % make test but you'd suggest to run: % ./Build test not only it'll confuse the user, who aren't aware of Build or t/TEST (in caes of Makemaker) existance, but it also won't do what you wanted the user to do. For example 'make test' in mp2 runs several tests suites and also ensures to print a bug report banner. t/TEST will run only one test suite and won't print the banner (unless the flag -bugreport flag will be passed). All I'm saying is that it could be confusing if they ran './build test' and you're asking them to run 'make test'. But FWIW, I see this type of problem all the time. For example, CPAN and CPANPLUS will prompt you to run 'make install UNINST=1' when they notice older versions of a module you're installing, even if the module is using Module::Build and needs to run './Build install uninst=1'. I don't know of a simple answer to this problem, but using 'make install' is probably the simplest thing to do for the time being. Ideally you'd know what was the original command they have executed, but it's not possible. The most correct answer would be $0, since they will at least get to run the correct part if it was a bigger 'make test' or something else. Alternatively we could say: giving up after 121 secs. If you think that your system is slow or overloaded try again with a longer timeout value. For example set the env var APACHE_TEST_STARTUP_TIMEOUT to a longer value, e.g. 400 and repeat the last command. But can we trust the user to know how to set an env var? May be we should. Of course in my proposed wording: % APACHE_TEST_STARTUP_TIMEOUT=420 make test wont' work on C-shell complient systems, and hopefully they have /bin/env or a built-in 'env' function. So may be the above suggestion is the best. The only reason I mentioned -startup_timeout=420 is that if they have already used that option, APACHE_TEST_STARTUP_TIMEOUT won't take an effect, since command line options override env vars. But may be they will figure it out on their own. Really, what I'm after is to give users as many hints as possible to get their side's problem resolved by themselves before they waste their and my time submitting a bug which is not. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [A-T patch] give a hint how to raise the timeout
Stas Bekman wrote: Well, you could still say Or repeat the last command with the -startup_timeout=420 option. That would work, if the last command was 'make test' or any other wrapper. s/would/won't/ -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestServer.pm
Philippe M. Chiasson wrote:
On Thu, 2004-03-04 at 22:21 +, [EMAIL PROTECTED] wrote:
geoff 2004/03/04 14:21:27
Modified:perl-framework/Apache-Test Changes
perl-framework/Apache-Test/lib/Apache TestServer.pm
Log:
$ENV{APACHE_TEST_STARTUP_TIMEOUT} now supersedes -startup_timeout
[...]
What's the reason for this change? I almost always expect that command
line arguments supercede env variables.. i.e.
$ CVSROOT=foo cvs -d bar co foo
Bad CVSROOT: `bar'.
What you can see should win over what you can't see, IMO
Yup, I've already pointed that out. I guess Geoff is not around.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestServer.pm
$ENV{APACHE_TEST_STARTUP_TIMEOUT} now supersedes -startup_timeout
[...]
What's the reason for this change?
it was a follow up from something on modperl@
I almost always expect that command
line arguments supercede env variables.. i.e.
$ CVSROOT=foo cvs -d bar co foo
Bad CVSROOT: `bar'.
What you can see should win over what you can't see, IMO
yeah, I thought about this after committing it - it's definitely better the
way it was. but it leaves mod_perl users in a lurch if they want to up the
startup time. the better solution is probably to have ModPerl::TestRun look
at %ENV before it sets the startup timeout.
I'll fit that tomorrow unless you or stas beat me to it.
--Geoff
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfigC.pm
+my $dversion = $self-server-dversion;
+if ($dversion eq '-DAPACHE1') {
that's '-D APACHE1' in current cvs, no?
--Geoff
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfigC.pm
Geoffrey Young wrote:
+my $dversion = $self-server-dversion;
+if ($dversion eq '-DAPACHE1') {
that's '-D APACHE1' in current cvs, no?
so i saw, when my tests blew up.
--
#kenP-)}
Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/
Author, developer, opinionist http://Apache-Server.Com/
Millennium hand and shrimp!
Re: mod_ssl TLS/SSL upgrade...
On Thu, Mar 04, 2004 at 09:08:28PM -0700, Brad Nicholes wrote: I would like to resurrect an old discussion. About a year and half ago rbb and wrowe committed a patch for mod_ssl to provide the SSLEngine upgrade capability. It seems that one of the reasons for not back porting it to the 2.0 tree was because there weren't really any clients that supported it. Well I know of at least one now which is Novell's iPrint client and I suspect that there may be others out there. Does anyone see any major issues with backporting this functionality to 2.0? There are still some protocol bugs: the client should be able to upgrade on any request not just an OPTIONS request, and the checking of the Connection header is wrong and unnecessary. It looks like it will break if a client sends an Upgrade header on a request with a body, too. (there is no deployment of 2817-style upgrades outside IPP because the protocol is broken w.r.t HTTP proxies, hence is not generally useful) joe
About time for 2.0.49?
Hi, It's been a while since last release. I'd like to volunteer for the RM task for 2.0.49, starting the release cycle monday. Thoughts? Sander
Re: About time for 2.0.49?
Sander Striker wrote: Hi, It's been a while since last release. I'd like to volunteer for the RM task for 2.0.49, starting the release cycle monday. Thoughts? yes, way too many fixes building up a couple of nags: There are some very simple mod_isapi fixes waiting for a backport, needing another vote. I'd also like some opinions in STATUS on whether or not we should wait for BeOS and OS/2 MPMs to support mpm state query before all the other 2.0 users can get the piped logger fixes. (No interest here in trying to add support to MPMs I can't compile/run and then trying to get approval to backport such questionable code.)
Re: [PATCH] httpd 1.3 denial of service with multiple listening sockets
Joe Orton wrote: On Fri, Mar 05, 2004 at 12:58:04AM -0800, Justin Erenkrantz wrote: --On Friday, March 5, 2004 12:53 AM -0800 Justin Erenkrantz [EMAIL PROTECTED] wrote: Doesn't that mean that ap_config.h needs to set NONBLOCK_WHEN_MULTI_LISTEN for the AIX 5.2 case? -- justin Realizing of course the following snippet in STATUS: On AIX, this only affects certain maintenance levels of 5.2 and the next kernel update will revert the possibility of accept blocking, so the logic will not be automatically enabled for AIX. I'm not sold that *not* doing this for AIX 5.2 is a good idea esp. considering that's where you found this initially. Yeah, agreed. fair enough ;) In general it might be prudent to have this feature on by default and hence secure by default, and whitelist it to off for the few platforms which have been tested to not have the select-pops-but-accept-blocks behaviour. That was my first take, but then it became difficult to reproduce the problem on most platforms I have access too. But there can be obscure race conditions in a kernel that we can't hope to reproduce at will. Except when a kernel savant can give a definitive ruling, it is best to eat the extra overhead. So, I disagree. Is there some way to only enable this if you aren't on the latest AIX maint. levels? (No clue what preprocessor macros you have available.) -- justin
win32 on VC++ 5.0
hi all. a few win32 things :) I'm trying to get 2.0.48 to compile using VC++ 5.0 (sp1) on win2k (sp4) and am having a few issues. yeah, I know it's old, but I happen to have it around and it's all I have :) anyway, since I'm not a windows guy, some of this might be common knowledge, but I couldn't find anything on google. - http://httpd.apache.org/docs-2.0/platform/win_compiling.html suggests I need the Platform SDK, but the link is stale. in fact, I can't find it anywhere on the MS site - MS has a download page for it, but it's borked. so, is there more recent information such that the docs ought to be updated? - since the SDK is only suggested, I tried compiling anyway. I get to apr-util/rand.c and it throws this: rand.c C:\httpd-2.0.48\srclib\apr\misc\win32\rand.c(102) : error C2065: 'HRESULT' : undeclared identifier C:\httpd-2.0.48\srclib\apr\misc\win32\rand.c(102) : error C2064: term does not evaluate to a function C:\httpd-2.0.48\srclib\apr\misc\win32\rand.c(102) : warning C4013: 'UuidCreate' undefined; assuming extern returning int C:\httpd-2.0.48\srclib\apr\misc\win32\rand.c(102) : error C2065: 'UUID' : undeclared identifier is this a known issue? should I report it to apr? or maybe 5.0 just isn't supported anymore? I'll accept that it's because I have no idea what I'm doing on this platform :) - lastly, is it possible/practical to have httpd 2.0 and 2.1 CVS snapshots include the win foo so I can attempt a fairly recent version of everything? anyway, thanks for any feedback. --Geoff
Re: win32 on VC++ 5.0
Geoffrey Young wrote: I seem to recall there being a perl script to convert the 6.0 project files to 5.0 format. If it exists, it will be in the source distribution. Perhaps it is in 1.3 distro? No time to check now. Bill
Re: win32 on VC++ 5.0
Geoffrey Young wrote: hi all. a few win32 things :) I'm trying to get 2.0.48 to compile using VC++ 5.0 (sp1) on win2k (sp4) and am having a few issues. yeah, I know it's old, but I happen to have it around and it's all I have :) anyway, since I'm not a windows guy, some of this might be common knowledge, but I couldn't find anything on google. - http://httpd.apache.org/docs-2.0/platform/win_compiling.html suggests I need the Platform SDK, but the link is stale. in fact, I can't find it anywhere on the MS site - MS has a download page for it, but it's borked. so, is there more recent information such that the docs ought to be updated? It's currently at: http://www.microsoft.com/msdownload/platformsdk/sdkupdate/home.htm although MS seem to change most of their links every week ;) I don't think you need the Platform SDK for VC++ 6.0; I don't know about 5.0. If you do need it, then it's probably just the Core SDK component that you need. You also need IE 5.0 or later to be able to use most of their download sites! - since the SDK is only suggested, I tried compiling anyway. I get to apr-util/rand.c and it throws this: rand.c C:\httpd-2.0.48\srclib\apr\misc\win32\rand.c(102) : error C2065: 'HRESULT' : undeclared identifier C:\httpd-2.0.48\srclib\apr\misc\win32\rand.c(102) : error C2064: term does not evaluate to a function C:\httpd-2.0.48\srclib\apr\misc\win32\rand.c(102) : warning C4013: 'UuidCreate' undefined; assuming extern returning int C:\httpd-2.0.48\srclib\apr\misc\win32\rand.c(102) : error C2065: 'UUID' : undeclared identifier is this a known issue? should I report it to apr? or maybe 5.0 just isn't supported anymore? I'll accept that it's because I have no idea what I'm doing on this platform :) I've never seen that using VC++ 6.0. HRESULT is declared thus: typedef LONG HRESULT; in my COMMCTRL.h. Do you have that header file (mine's in C:\Program Files\Microsoft Visual Studio\VC98\Include; yours will be somewhere slightly different but similar if you have it)? Does it contain that declaration? If you're missing the header or the declaration in it, then perhaps you do need the Platform SDK... - lastly, is it possible/practical to have httpd 2.0 and 2.1 CVS snapshots include the win foo so I can attempt a fairly recent version of everything? I'll second that request. I was recently trying to build the latest (CVS) httpd-2.0 on Win32 (probably to look at the same thing that Geoff's trying to look at!), but couldn't because all the extra *.mak files etc that are in the httpd-2.0.48-win32-src.zip but not the httpd-2.0.48.tar.gz are not on CVS (or at least not where I could find them). - Steve Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
Re: win32 on VC++ 5.0
At 09:23 AM 3/5/2004, Steve Hay wrote: Geoffrey Young wrote: I'm trying to get 2.0.48 to compile using VC++ 5.0 (sp1) on win2k (sp4) and am having a few issues. yeah, I know it's old, but I happen to have it around and it's all I have :) anyway, since I'm not a windows guy, some of this might be common knowledge, but I couldn't find anything on google. It's currently at: http://www.microsoft.com/msdownload/platformsdk/sdkupdate/home.htm although MS seem to change most of their links every week ;) I hate even including the links as they are staled often. I don't think you need the Platform SDK for VC++ 6.0; I don't know about 5.0. If you do need it, then it's probably just the Core SDK component that you need. You also need IE 5.0 or later to be able to use most of their download sites! Yes. VC5.0's featureset is pre Win2k - pre NT SP3. so using 5.0 ... I get to apr-util/rand.c and it throws this: rand.c C:\httpd-2.0.48\srclib\apr\misc\win32\rand.c(102) : error C2065: 'HRESULT' : undeclared identifier C:\httpd-2.0.48\srclib\apr\misc\win32\rand.c(102) : error C2065: 'UUID' : undeclared identifier I've never seen that using VC++ 6.0. I wouldn't expect so and no - the SDK is required for visual studio 5.0 - this wont be the last thing you trip over. - lastly, is it possible/practical to have httpd 2.0 and 2.1 CVS snapshots include the win foo so I can attempt a fairly recent version of everything? I'll second that request. We don't generate .mak files in CVS - it is not practical - the changes are not worth the investment. However, with awk (awk95 works well) in your path, you can use the interactive apache.dsw to build the project under 5.0 - under 6.0 we build on the command line from dsp/dsw 's. Look in the cvs attic of apache-1.3 for any .mak files and you will see why we decided to make them part of rolling the package. http://cvs.apache.org/viewcvs.cgi/apache-1.3/src/ApacheCore.mak?hideattic=0 vs http://cvs.apache.org/viewcvs.cgi/apache-1.3/src/ApacheCore.dsp?hideattic=0 the cvs ,v files are 362k vs 43k w/ about 50 revs each. The delta of a .dsp is legible, for .mak files they are not. . Bill
Re: mod_ssl TLS/SSL upgrade...
Brad I'm plus 1, especially if we can cause libwww to instigate this connection mode for httpd-test and prove that it behaves per the RFC convention. But I have a better proposal - let us simply move back the entire mod_ssl 2.1 back to 2.0. Only binary compat issues would need review. But too many good things have happened on 2.1 to this specific component. I'll propose SSL-C and win32 build solutions I've adopted for Covalent's build farm, over the next few days into 2.1. note that the 2.1 rewrite of the autoconf .m4 stuff made thins much worse - I use a simple hack on top of the 2.0 build scripts. When we declare 2.1 baked, we should shift that module back :) My QA folks have done extensive work wrt 2.1 (up to the last two weeks of rapid patches) and have found it very well suited to build under 2.0.48, compared to the 2.0 flavor. Bill At 10:08 PM 3/4/2004, Brad Nicholes wrote: I would like to resurrect an old discussion. About a year and half ago rbb and wrowe committed a patch for mod_ssl to provide the SSLEngine upgrade capability. It seems that one of the reasons for not back porting it to the 2.0 tree was because there weren't really any clients that supported it. Well I know of at least one now which is Novell's iPrint client and I suspect that there may be others out there. Does anyone see any major issues with backporting this functionality to 2.0? If not then I would like to propose it for back port and see if we can get it done. The attached patch can be applied to the 2.0 branch. HEAD already contains all of the patches. Here (http://www.apache.org/~bnicholes/wget_tls_prelim-1.8.2.tar.gz)is a hacked version of wget that is able to test the functionality. Invoke wget with the -u parameter to allow it to request the TLS/SSL upgraded connection. Brad At 11:46 AM 10/15/2002, [EMAIL PROTECTED] wrote: [snip] The second is SSL upgrade. I have the patches, they haven't been committed yet. I have attached them at the bottom of this message. The reason they haven't been committed, is that I don't have a client to test them with, and I haven't had time to create one. The responses are correct I have checked them in plain text. The place that bugs most likely exist, is the actual upgrade code that does the handshake. This is an important feature, and I would really like to see it in 2.0. I see a couple of very important aspects to this patch: 1) we must have an implementation of connection: upgrade for libwww, since that is the mechanism we use for httpd-test/perl-framework. I don't have such a fix, so I'm just asking the community if anyone has explored that avenue. 2) it has to be maintained. I've looked at this patch, it appears quite correct. I'm going to begin working on applying it to cvs HEAD. I'm not concerned about it quickly appearing in 2.0 since there are no clients right now. I'm much more concerned about it's availability once clients can support it. 3) right now, the ssl code (ssl_engine_io) was already pretty heavily refactored. The patch wasn't easy to apply. We are discussing other refactorings that will make SSL much simpler to follow and far less error-prone. Those will effectively invalidate the effort Ryan has already invested. My proposed solution is to review the patch and apply it to cvs HEAD. Get it committed. Of course there are no test suites right now, and there won't be for a little while yet. But once the code exists, it will be simpler to keep the SSL upgrade facility maintained, and debug it as the clients become available (most especially, libwww exercises through perl-framework.) Any disagreement? The current patch that applies to cvs HEAD is attached. Bill Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com
Re: mod_ssl TLS/SSL upgrade...
--On Friday, March 5, 2004 12:20 AM -0600 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: But I have a better proposal - let us simply move back the entire mod_ssl 2.1 back to 2.0. Only binary compat issues would need review. But too many good things have happened on 2.1 to this specific component. I'd rather just start the 2.2 release cycle than do that. -- justin
Re: mod_ssl TLS/SSL upgrade...
I would really like to get the TLS/SSL upgrade functionality into the 2.0.49 release. If Sander is wanting to start the relase on Monday, I would like to do whatever is easiest to get this patch in. Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com [EMAIL PROTECTED] Thursday, March 04, 2004 11:20:31 PM Brad I'm plus 1, especially if we can cause libwww to instigate this connection mode for httpd-test and prove that it behaves per the RFC convention. But I have a better proposal - let us simply move back the entire mod_ssl 2.1 back to 2.0. Only binary compat issues would need review. But too many good things have happened on 2.1 to this specific component. I'll propose SSL-C and win32 build solutions I've adopted for Covalent's build farm, over the next few days into 2.1. note that the 2.1 rewrite of the autoconf .m4 stuff made thins much worse - I use a simple hack on top of the 2.0 build scripts. When we declare 2.1 baked, we should shift that module back :) My QA folks have done extensive work wrt 2.1 (up to the last two weeks of rapid patches) and have found it very well suited to build under 2.0.48, compared to the 2.0 flavor. Bill At 10:08 PM 3/4/2004, Brad Nicholes wrote: I would like to resurrect an old discussion. About a year and half ago rbb and wrowe committed a patch for mod_ssl to provide the SSLEngine upgrade capability. It seems that one of the reasons for not back porting it to the 2.0 tree was because there weren't really any clients that supported it. Well I know of at least one now which is Novell's iPrint client and I suspect that there may be others out there. Does anyone see any major issues with backporting this functionality to 2.0? If not then I would like to propose it for back port and see if we can get it done. The attached patch can be applied to the 2.0 branch. HEAD already contains all of the patches. Here (http://www.apache.org/~bnicholes/wget_tls_prelim-1.8.2.tar.gz)is a hacked version of wget that is able to test the functionality. Invoke wget with the -u parameter to allow it to request the TLS/SSL upgraded connection. Brad At 11:46 AM 10/15/2002, [EMAIL PROTECTED] wrote: [snip] The second is SSL upgrade. I have the patches, they haven't been committed yet. I have attached them at the bottom of this message. The reason they haven't been committed, is that I don't have a client to test them with, and I haven't had time to create one. The responses are correct I have checked them in plain text. The place that bugs most likely exist, is the actual upgrade code that does the handshake. This is an important feature, and I would really like to see it in 2.0. I see a couple of very important aspects to this patch: 1) we must have an implementation of connection: upgrade for libwww, since that is the mechanism we use for httpd-test/perl-framework. I don't have such a fix, so I'm just asking the community if anyone has explored that avenue. 2) it has to be maintained. I've looked at this patch, it appears quite correct. I'm going to begin working on applying it to cvs HEAD. I'm not concerned about it quickly appearing in 2.0 since there are no clients right now. I'm much more concerned about it's availability once clients can support it. 3) right now, the ssl code (ssl_engine_io) was already pretty heavily refactored. The patch wasn't easy to apply. We are discussing other refactorings that will make SSL much simpler to follow and far less error-prone. Those will effectively invalidate the effort Ryan has already invested. My proposed solution is to review the patch and apply it to cvs HEAD. Get it committed. Of course there are no test suites right now, and there won't be for a little while yet. But once the code exists, it will be simpler to keep the SSL upgrade facility maintained, and debug it as the clients become available (most especially, libwww exercises through perl-framework.) Any disagreement? The current patch that applies to cvs HEAD is attached. Bill Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com
Re: mod_ssl TLS/SSL upgrade...
Brad Nicholes wrote: I would really like to get the TLS/SSL upgrade functionality into the 2.0.49 release. If Sander is wanting to start the relase on Monday, I would like to do whatever is easiest to get this patch in. Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com I'll ditto the desire, but not the offer to help, unfortunately... -- Jess Holle
RE: mod_ssl TLS/SSL upgrade...
-Original Message- From: Justin Erenkrantz [mailto:[EMAIL PROTECTED] [SNIP] --On Friday, March 5, 2004 12:20 AM -0600 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: But I have a better proposal - let us simply move back the entire mod_ssl 2.1 back to 2.0. Only binary compat issues would need review. But too many good things have happened on 2.1 to this specific component. I'd rather just start the 2.2 release cycle than do that. -- justin I think a lot of good things have gone into the mod_ssl 2.1 - if we start with 2.2, we may still have to back-port the majority of fixes to 2.0 (as customers may not jump immediately to 2.2). -Madhu
Re: mod_ssl TLS/SSL upgrade...
At 11:11 AM 3/5/2004, Brad Nicholes wrote: I would really like to get the TLS/SSL upgrade functionality into the 2.0.49 release. If Sander is wanting to start the relase on Monday, I would like to do whatever is easiest to get this patch in. -1 - too big a change too late in the cycle. +1 for 2.0.50 Bill
Re: win32 on VC++ 5.0
William A. Rowe, Jr. wrote: At 09:23 AM 3/5/2004, Steve Hay wrote: Geoffrey Young wrote: - lastly, is it possible/practical to have httpd 2.0 and 2.1 CVS snapshots include the win foo so I can attempt a fairly recent version of everything? I'll second that request. We don't generate .mak files in CVS - it is not practical - the changes are not worth the investment. However, with awk (awk95 works well) in your path, you can use the interactive apache.dsw to build the project under 5.0 - under 6.0 we build on the command line from dsp/dsw 's. How do you build on the command line from the .dsp/.dsw's? The win_compiling.html document that Geoff referred to explains either using Makefile.win from the command-line (which presumably requires the .mak files), or else using the .dsp/.dsw files from the IDE. There is no mention of how to use the .dsp/.dsw's from the command-line. I tried using msdev.exe on the command-line with various .dsp/.dsw, /MAKE, /USEENV options, but couldn't get anything to work. Some instructions would be greatly appreciated if this is the way things are done ;) - Steve Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
RE: mod_ssl TLS/SSL upgrade...
At 11:19 AM 3/5/2004, Mathihalli, Madhusudan wrote: -Original Message- From: Justin Erenkrantz [mailto:[EMAIL PROTECTED] [SNIP] --On Friday, March 5, 2004 12:20 AM -0600 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: But I have a better proposal - let us simply move back the entire mod_ssl 2.1 back to 2.0. Only binary compat issues would need review. But too many good things have happened on 2.1 to this specific component. I'd rather just start the 2.2 release cycle than do that. -- justin I think a lot of good things have gone into the mod_ssl 2.1 - if we start with 2.2, we may still have to back-port the majority of fixes to 2.0 (as customers may not jump immediately to 2.2). Or to say it very simply - only one patch - connection upgrade - didn't really belong in 2.0 - yet it is harder and harder to keep in sync while dancing around that patch. Bill
Re: win32 on VC++ 5.0
It's currently at: http://www.microsoft.com/msdownload/platformsdk/sdkupdate/home.htm although MS seem to change most of their links every week ;) ugh. I found that but wasn't using msie so the js errors kept be from seeing the dropdowns. I don't think you need the Platform SDK for VC++ 6.0; I don't know about 5.0. If you do need it, then it's probably just the Core SDK component that you need. for the archives, I also needed the Internet Developer SDK to resolve some issues with winldap.h calling missing files. actually, all of ldap was a pain - I ended up disabling mod_auth_ldap to get past the issues. You also need IE 5.0 or later to be able to use most of their download sites! go figure. HRESULT is declared thus: typedef LONG HRESULT; in my COMMCTRL.h. Do you have that header file I have the file but no declaration. the core sdk conains the file as well with the declaration, so adding the sdk include path before the visual studio paths worked. it compiled (with 118 warnings). so, thanks for the help. --Geoff
Re: win32 on VC++ 5.0
At 11:32 AM 3/5/2004, Steve Hay wrote: How do you build on the command line from the .dsp/.dsw's? The win_compiling.html document that Geoff referred to explains either using Makefile.win from the command-line (which presumably requires the .mak files), or else using the .dsp/.dsw files from the IDE. There is no mention of how to use the .dsp/.dsw's from the command-line. look at makefile.win - that is its job. Bill
Re: cvs commit: httpd-2.0 libhttpd.dsp
William A. Rowe, Jr. wrote: uh wrong. with /debug incremental yes is the default but you have to pound it into the msdev's head. please fix/revert. -# ... /dll /incremental:no /debug /machine:I386 /base:@os\win32\BaseAddr.ref,libhttpd.dll /opt:ref +# ... /dll /debug /machine:I386 /base:@os\win32\BaseAddr.ref,libhttpd.dll /opt:ref Looks like MSDEV fooness to me. I changed nothing in the project except adding the eoc file but I can't coax MSDEV into including /incremental:no in the dsp even though it *is* there in the Link Project Options box. Since I don't want to manually edit the generated file the only thing I can do is revert the checkin and let someone else (Bill?) add the eoc file back in. Allan
RE: cvs commit: httpd-2.0 libhttpd.dsp
From: Allan Edwards [mailto:[EMAIL PROTECTED] Sent: Friday, March 05, 2004 7:38 PM William A. Rowe, Jr. wrote: uh wrong. with /debug incremental yes is the default but you have to pound it into the msdev's head. please fix/revert. -# ... /dll /incremental:no /debug /machine:I386 /base:@os\win32\BaseAddr.ref,libhttpd.dll /opt:ref +# ... /dll /debug /machine:I386 /base:@os\win32\BaseAddr.ref,libhttpd.dll /opt:ref Looks like MSDEV fooness to me. I changed nothing in the project except adding the eoc file but I can't coax MSDEV into including /incremental:no in the dsp even though it *is* there in the Link Project Options box. Since I don't want to manually edit the generated file the only thing I can do is revert the checkin and let someone else (Bill?) add the eoc file back in. I'll go and hand edit it then. Sander
mod_deflate - disabling per response?
My apologies if this is better done on the user group, but I've been reading Apache source code and trying to understand the following. Is there any way to signal mod_deflate that a particular response should not be deflated when: the URL of the request is identical to other cases that should be deflated, the MIME type of the response is identical to other cases that should be deflated, and the response is not already compressed/deflated? Essentially request parameters, data states, Java server logic, etc, behind mod_jk (or mod_jk2) will dictate whether compression can be allowed, but I need a way to signal this in my response from Tomcat. Any pointers would be much appreciated! -- Jess Holle
Re: win32 on VC++ 5.0
I hate even including the links as they are staled often. yeah. but here's a patch anyway that at least matches my recent experience. if it looks ok to the people that use the platform regularly I'll hand it over to httpd-docs. --Geoff
Re: win32 on VC++ 5.0
blarg. patch attached Geoffrey Young wrote: I hate even including the links as they are staled often. yeah. but here's a patch anyway that at least matches my recent experience. if it looks ok to the people that use the platform regularly I'll hand it over to httpd-docs. --Geoff Index: docs/manual/platform/win_compiling.xml === RCS file: /home/cvspublic/httpd-2.0/docs/manual/platform/win_compiling.xml,v retrieving revision 1.7 diff -u -r1.7 win_compiling.xml --- docs/manual/platform/win_compiling.xml 9 Feb 2004 20:22:51 - 1.7 +++ docs/manual/platform/win_compiling.xml 5 Mar 2004 18:37:31 - @@ -65,7 +65,7 @@ li pThe Windows Platform SDK./p pVisual C++ 5.0 builds require an updated Microsoft Windows -Platform SDK to enable some Apache features. For command line +Platform SDK to compile. For command line builds, the Platform SDK environment is prepared by the codesetenv/code batch file:/p @@ -77,13 +77,9 @@ later are sufficient, so users of later version may skip this requirement./p -noteNote that the Windows Platform SDK update is required -to enable all supported modulemod_isapi/module features. -Without a recent update, Apache will issue warnings under -MSVC++ 5.0 that some modulemod_isapi/module features -will be disabled. Look for the update at a -href=http://msdn.microsoft.com/downloads/sdks/platform/platform.asp; -http://msdn.microsoft.com/downloads/sdks/platform/platform.asp/a./note +noteLook for the Platform SDK at a +href=http://www.microsoft.com/msdownload/platformsdk/sdkupdate/home.htm; + http://www.microsoft.com/msdownload/platformsdk/sdkupdate/home.htm/a./note /li li
Re: cvs commit: httpd-2.0 libhttpd.dsp
At 12:37 PM 3/5/2004, Allan Edwards wrote: Looks like MSDEV fooness to me. I changed nothing in the project except adding the eoc file but I can't coax MSDEV into including /incremental:no in the dsp even though it *is* there in the Link Project Options box. this is why I always add sources (in alpha order as some DevStudio versions seem to prefer) by hand. Yes DevStudio is brain dead on this and other points. Bill
RE: cvs commit: httpd-2.0 libhttpd.dsp
From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED] Sent: Friday, March 05, 2004 7:43 PM At 12:37 PM 3/5/2004, Allan Edwards wrote: Looks like MSDEV fooness to me. I changed nothing in the project except adding the eoc file but I can't coax MSDEV into including /incremental:no in the dsp even though it *is* there in the Link Project Options box. this is why I always add sources (in alpha order as some DevStudio versions seem to prefer) by hand. Yes DevStudio is brain dead on this and other points. You know, those python build system changes that went into apr the other day... :) Sander
Re: mod_deflate - disabling per response?
Jess Holle wrote: My apologies if this is better done on the user group, but I've been reading Apache source code and trying to understand the following. Is there any way to signal mod_deflate that a particular response should not be deflated when: 1. the URL of the request is identical to other cases that should be deflated, 2. the MIME type of the response is identical to other cases that should be deflated, and 3. the response is not already compressed/deflated? Essentially request parameters, data states, Java server logic, etc, behind mod_jk (or mod_jk2) will dictate whether compression can be allowed, but I need a way to signal this in my response from Tomcat. Any pointers would be much appreciated! really, it's the client that decides whether the content should be encoded or not, which they typically do by setting an Accept-Encoding request header. so remove that in the client and no compression. from the server side, it looks like you can set use the subprocess_env table to suppress it if you have access to the API apr_table_setn(r-subprocess_env, no-gzip); not sure if either of these suits you, though. HTH --Geoff
Re: mod_deflate - disabling per response?
Geoffrey Young wrote: Jess Holle wrote: My apologies if this is better done on the user group, but I've been reading Apache source code and trying to understand the following. Is there any way to signal mod_deflate that a particular response should not be deflated when: 1. the URL of the request is identical to other cases that should be deflated, 2. the MIME type of the response is identical to other cases that should be deflated, and 3. the response is not already compressed/deflated? Essentially request parameters, data states, Java server logic, etc, behind mod_jk (or mod_jk2) will dictate whether compression can be allowed, but I need a way to signal this in my response from Tomcat. Any pointers would be much appreciated! really, it's the client that decides whether the content should be encoded or not, which they typically do by setting an Accept-Encoding request header. so remove that in the client and no compression. Normally, yes. My specific case is one where client timeouts are prevented through periodic whitespace output with flushes (in HTML responses) when the server knows it has been thinking too long. One might debate the wisdom of that strategy -- but it is pre-existing. Thus either I exclude the URLs that might show this behavior from the mod_deflate filtering (thus excluding a lot of other cases where mod_deflate *should* be used) or I find a way to signal "don't deflate me" in such responses. from the server side, it looks like you can set use the subprocess_env table to suppress it if you have access to the API apr_table_setn(r-subprocess_env, "no-gzip"); not sure if either of these suits you, though. Hmmm... What I'm really looking for is a response header or some such that I can set in my JSP page or servlet in Tomcat to indicate that the response should be left alone -- Jess Holle
