Re: Is Apache Proxy Half-Duplex?
Bill Stoddard wrote: This is a variation of the problem Aaron and I were interested in with CGI scripts (and directly related to an open PR against 2.0.36). Unfortunately, I think filters need some more work to make this possible. As Will said, we need to be able to poll/select on both the frontend and backend descriptors and do the right thing. I may be mistaken but I thought the proxy in 1.3 handled this correctly... The v1.3 proxy was always read request then read response, it never did these two simultaneously. Would the changes to the filters be that drastic? We would in theory just have to poll for incoming data (in either direction), then read bridages from the relevant filter stack...? No...? Regards, Graham -- - [EMAIL PROTECTED]There's a moon over Bourbon Street tonight... smime.p7s Description: S/MIME Cryptographic Signature
Re: [PATCH] simplified apachectl that passes through options to httpd
Cliff Woolley [EMAIL PROTECTED] writes: On 23 May 2002, Jeff Trawick wrote: Existing apachectl keywords are still supported for now (except for some alternate spellings of startssl -- whats up with that stuff?). I always assumed it was for Apache-SSL compatibility. Ben? google finds lots of hits for sslstart. The only hits for start-SSL I see so far are from the apachectl usage message. I've added support back in for the alternate spellings for the time being: sslstart|start-SSL) $HTTPD -k startssl ERROR=$? ;; (well, I'm calling anything but startssl an alternate spelling; I dunno what came first, but it is -k startssl which httpd supports) -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
RE: Is Apache Proxy Half-Duplex?
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Bill Stoddard wrote: This is a variation of the problem Aaron and I were interested in with CGI scripts (and directly related to an open PR against 2.0.36). Unfortunately, I think filters need some more work to make this possible. As Will said, we need to be able to poll/select on both the frontend and backend descriptors and do the right thing. I may be mistaken but I thought the proxy in 1.3 handled this correctly... The v1.3 proxy was always read request then read response, it never did these two simultaneously. Would the changes to the filters be that drastic? We would in theory just have to poll for incoming data (in either direction), then read bridages from the relevant filter stack...? No...? I tried to think through how to do this back in November, when I last touched the proxy. The easiest way to do this, is to add a new read mode to input filters, APR_READ_POLL. Each filter would be responsible for returning any data that it has if called in this mode. If none of the filters in the stack have any data, then the filter that has the socket must return the socket bucket, but it is allowed to keep a copy of the socket itself. The filter_poll call can then use apr_poll to determine which of the sockets have any data. This wouldn't be the cleanest code, but it should work. Ryan
Re: [PATCH] simplified apachectl that passes through options to httpd
At 06:20 AM 5/24/2002, you wrote: Cliff Woolley [EMAIL PROTECTED] writes: On 23 May 2002, Jeff Trawick wrote: Existing apachectl keywords are still supported for now (except for some alternate spellings of startssl -- whats up with that stuff?). sslstart|start-SSL) $HTTPD -k startssl ERROR=$? ;; (well, I'm calling anything but startssl an alternate spelling; I dunno what came first, but it is -k startssl which httpd supports) Can I ask WHY? -k has never supported anything but start/stop/restart and has always required a seperate -D SSL argument on Win32. I see the advantage of a simple apachectl doit verb that includes ssl. However, overloading -k start -D SSL with -k startssl seems outright silly. We can't argue back-compat here, -k didn't exist before. Not that win32 was complete... -k stop should probably stop-graceful while -k shutdown on win32 should probably slam it all down fast. Likewise we should probably be adding -k graceful for what we do today with -k restart, and let -k restart to hard shutdowns of open connections. This is similar to the -X debate, with one huge exception. -X has been around for a very long time :-) Bill
Re: Is Apache Proxy Half-Duplex?
I really want to spend some time on this (when I have some time to spend on it). As part of this work, we need to consider what needs to be done to the filter API to support an event driven MPM. Need to get this prioritized above the other stuff I'm working on :-( Bill From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Bill Stoddard wrote: This is a variation of the problem Aaron and I were interested in with CGI scripts (and directly related to an open PR against 2.0.36). Unfortunately, I think filters need some more work to make this possible. As Will said, we need to be able to poll/select on both the frontend and backend descriptors and do the right thing. I may be mistaken but I thought the proxy in 1.3 handled this correctly... The v1.3 proxy was always read request then read response, it never did these two simultaneously. Would the changes to the filters be that drastic? We would in theory just have to poll for incoming data (in either direction), then read bridages from the relevant filter stack...? No...? I tried to think through how to do this back in November, when I last touched the proxy. The easiest way to do this, is to add a new read mode to input filters, APR_READ_POLL. Each filter would be responsible for returning any data that it has if called in this mode. If none of the filters in the stack have any data, then the filter that has the socket must return the socket bucket, but it is allowed to keep a copy of the socket itself. The filter_poll call can then use apr_poll to determine which of the sockets have any data. This wouldn't be the cleanest code, but it should work. Ryan
Re: [PATCH] simplified apachectl that passes through options to httpd
Cliff Woolley wrote: On 23 May 2002, Jeff Trawick wrote: Existing apachectl keywords are still supported for now (except for some alternate spellings of startssl -- whats up with that stuff?). I always assumed it was for Apache-SSL compatibility. Ben? Apache-SSL always has SSL (surprise!), so just plain start suffices. Cheers, Ben.
Re: Tagging 2.0.37
Sander Striker wrote: Hi, What about tagging the tree on monday? Thoughts? FWIW the worker MPM in 2.0.36 is broken and will deadlock under high loads. Can you wait until we make sure that brian's patch fixes it? I would also like to see the hi-free apr-pool patch in as well Sander
Re: Tagging 2.0.37
Ian Holsman [EMAIL PROTECTED] wrote: Sander Striker wrote: Hi, What about tagging the tree on monday? Thoughts? FWIW the worker MPM in 2.0.36 is broken and will deadlock under high loads. Can you wait until we make sure that brian's patch fixes it? I would also like to see the hi-free apr-pool patch in as well I can set it up on Nagoya, but up until now, we never hit that much load to make 2.0.36 die... Will do it tomorrow... Pier
Re: Tagging 2.0.37
HEAD will not start as a service on Windows. Not sure exactly when of what broke it. Bill - Original Message - From: Sander Striker [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, May 24, 2002 2:47 AM Subject: Tagging 2.0.37 Hi, What about tagging the tree on monday? Thoughts? Sander
Re: Tagging 2.0.37
On Fri, May 24, 2002 at 08:12:18AM -0700, Ian Holsman wrote: Can you wait until we make sure that brian's patch fixes it? I would also like to see the hi-free apr-pool patch in as well I'm -0.9 on the hi-free patch unless we can get some performance numbers. But, I don't think the hi-free patch would prevent me from voting for a release. -aaron
Re: Tagging 2.0.37
I presume the -k patch... since apache -k start -n apache2 dumps the usage message. Forget about a Monday tag, folks. Late in the week, perhaps? There are four other boffo bugs I'd like to have a chance to look at before inflicting .37 on the world: 1. Fix apr_file_read() so that we don't crash on the first read in rotatelogs. Win32's implementation appears to have been borked in overeagerness to work around unusual read cases - we can't handle the simple ones. 2. Fix WinNT MPM to use apr_thread_create/apr_proc_create. The former is a simple fix, the later is required for folks who install Apache to a non- ASCII file path or who pass non-ASCII arguments on the command line. It's the last I18N hassle in Apache2. Essentially, I'm getting sick of us not eating our own dogfood ... those MS munchies may taste better, but where does it leave us? 3. Fix thread setup/teardown on winnt mpm. We are using non-threadsafe threadcount incr/dec operations. I've seen it deadlock with six 'running threads' when no threads were left, and while it might be a quirk, we really need to address it. 4. Cruft in apr-util that exports undecorated names from apr_strmatch. Bill At 10:29 AM 5/24/2002, you wrote: HEAD will not start as a service on Windows. Not sure exactly when of what broke it. Bill - Original Message - From: Sander Striker [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, May 24, 2002 2:47 AM Subject: Tagging 2.0.37 Hi, What about tagging the tree on monday? Thoughts? Sander
Re: [PATCH] simplified apachectl that passes through options to httpd
William A. Rowe, Jr. [EMAIL PROTECTED] writes: At 06:20 AM 5/24/2002, you wrote: Cliff Woolley [EMAIL PROTECTED] writes: On 23 May 2002, Jeff Trawick wrote: Existing apachectl keywords are still supported for now (except for some alternate spellings of startssl -- whats up with that stuff?). sslstart|start-SSL) $HTTPD -k startssl ERROR=$? ;; (well, I'm calling anything but startssl an alternate spelling; I dunno what came first, but it is -k startssl which httpd supports) Can I ask WHY? -k has never supported anything but start/stop/restart and has always required a seperate -D SSL argument on Win32. I see the advantage of a simple apachectl doit verb that includes ssl. However, overloading -k start -D SSL with -k startssl seems outright silly. We can't argue back-compat here, -k didn't exist before. I think that this is your main point (please confirm): don't support httpd -k startssl, and instead force the user (or apachectl) to run httpd -k startssl -DSSL One issue that may affect your opinion: historic apachectl verbs are to be considered deprecated; the vision is that apachectl is just a wrapper script whose user interface is the same as httpd. Thinking long-term (e.g., Apache 2.1 or whatever), would you want the user to have to do httpd -k start -DSSL instead of httpd -k startssl ? -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: [PATCH] simplified apachectl that passes through options to httpd
Jeff Trawick wrote: I think that this is your main point (please confirm): don't support httpd -k startssl, and instead force the user (or apachectl) to run httpd -k startssl -DSSL One issue that may affect your opinion: historic apachectl verbs are to be considered deprecated; the vision is that apachectl is just a wrapper script whose user interface is the same as httpd. Thinking long-term (e.g., Apache 2.1 or whatever), would you want the user to have to do httpd -k start -DSSL But there are tons of configs out there with the IfDef SSL directives in their httpd.conf file that want/expect/require that SSL is defined -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: Tagging 2.0.37
William A. Rowe, Jr. [EMAIL PROTECTED] writes: I presume the -k patch... since apache -k start -n apache2 dumps the usage message. Forget about a Monday tag, folks. Late in the week, perhaps? What are are you referring to? A bug? Seen on Windows only? Do you suspect a problem with the -k support added to the Unix MPMs (should not have touched any Win32 path except for the lookup of an optional function in main(), which would have failed for non-Unix right now). (ready to fix if I broke something, but currently perplexed) -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: Tagging 2.0.37
Sander Striker [EMAIL PROTECTED] writes: What about tagging the tree on monday? Thoughts? Maybe first somebody can come up with a better name for the ap_signal_server optional function which I added very recently. I didn't want to hold up the code until the naming police straightened it out, yet it feels a bit unclean to be releasing as an API. (Where's Greg when you need him?) -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: [PATCH] simplified apachectl that passes through options to httpd
At 10:52 AM 5/24/2002, you wrote: William A. Rowe, Jr. [EMAIL PROTECTED] writes: Can I ask WHY? -k has never supported anything but start/stop/restart and has always required a seperate -D SSL argument on Win32. I see the advantage of a simple apachectl doit verb that includes ssl. However, overloading -k start -D SSL with -k startssl seems outright silly. We can't argue back-compat here, -k didn't exist before. I think that this is your main point (please confirm): don't support httpd -k startssl, and instead force the user (or apachectl) to run httpd -k startssl -DSSL err... still a bit redundant, httpd -k start -DSSL should suffice [I'm pretty sure that's what you ment to ask :-] One issue that may affect your opinion: historic apachectl verbs are to be considered deprecated; the vision is that apachectl is just a wrapper script whose user interface is the same as httpd. Thinking long-term (e.g., Apache 2.1 or whatever), would you want the user to have to do httpd -k start -DSSL Yes. How many other server modules [protocols especially, such as pop3 and so on] will beg the same. It's bogus. If you configure your machine for SSL, then run it as SSL already!!! Why are we trying to say you've installed and configured SSL, so now you have to turn it on explicitly everytime you start up. Which most will take as meaning I have apache2 installed, so now all I need to do is to startssl and everything will work. Either the user installs and configures SSL correctly or they don't, I still don't see a benefit in this switch. Uncommenting and Commenting Out our Include ssl.conf should suffice, no? And if a user wants to use the 'classic' mode of toggling a variable [I did so very often when testing both jserv and tomcat, used -D JSERV and -D TOMCAT for that purpose since they can never load together], then do it explicitly before we start seeing -k starttomcat patches popping up everywhere. At 10:57 AM 5/24/2002, JimJag wrote: But there are tons of configs out there with the IfDef SSL directives in their httpd.conf file that want/expect/require that SSL is defined Apache 2.0 config files? Tons of them? Really :-? Seriously, dump the IfDefine. For most cases these should really be IfModule mod_ssl.c entities instead anyways. Only the load module itself aught to be caught in an IfDefine SSL. I fail to see how setting up ssl in Apache 2.0 should differ from setting up mod_pop3, mod_mbox, mod_jk or any other module. Bill
Re: Tagging 2.0.37
Dumping the usage_message because the argv/argc returned from mpm_rewrite_args has argc=4 but there is no 4th argument on argv. The 4th arg is being pulled from the registry: System/CurrentControlSet/apache2/ConfigArgs. ConfigArgs key exists but it has no value associated with it and I suspect this is the problem Bill I presume the -k patch... since apache -k start -n apache2 dumps the usage message. Forget about a Monday tag, folks. Late in the week, perhaps? There are four other boffo bugs I'd like to have a chance to look at before inflicting .37 on the world: 1. Fix apr_file_read() so that we don't crash on the first read in rotatelogs. Win32's implementation appears to have been borked in overeagerness to work around unusual read cases - we can't handle the simple ones. 2. Fix WinNT MPM to use apr_thread_create/apr_proc_create. The former is a simple fix, the later is required for folks who install Apache to a non- ASCII file path or who pass non-ASCII arguments on the command line. It's the last I18N hassle in Apache2. Essentially, I'm getting sick of us not eating our own dogfood ... those MS munchies may taste better, but where does it leave us? 3. Fix thread setup/teardown on winnt mpm. We are using non-threadsafe threadcount incr/dec operations. I've seen it deadlock with six 'running threads' when no threads were left, and while it might be a quirk, we really need to address it. 4. Cruft in apr-util that exports undecorated names from apr_strmatch. Bill At 10:29 AM 5/24/2002, you wrote: HEAD will not start as a service on Windows. Not sure exactly when of what broke it. Bill - Original Message - From: Sander Striker [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, May 24, 2002 2:47 AM Subject: Tagging 2.0.37 Hi, What about tagging the tree on monday? Thoughts? Sander
Re: [PATCH] simplified apachectl that passes through options to httpd
On Fri, May 24, 2002 at 11:10:25AM -0500, William A. Rowe, Jr. wrote: If you configure your machine for SSL, then run it as SSL already!!! Why are we trying to say you've installed and configured SSL, so now you have to turn it on explicitly everytime you start up. Which most will take as meaning I have apache2 installed, so now all I need to do is to startssl and everything will work. Simple: We have static and dynamic modules. Static modules can't turn off their LoadModule lines, so we can't use that to turn on and off the functionality in those modules. -DSSL is the runtime switch that mod_ssl uses to enable SSL functionality. -aaron
Re: cvs commit: httpd-2.0 libhttpd.dsp
I like! Will do some testing on NT 4. Bill - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, May 24, 2002 11:16 AM Subject: cvs commit: httpd-2.0 libhttpd.dsp wrowe 02/05/24 08:16:53 Modified:.libhttpd.dsp Log: We appear to never have had any complaints about copy srcname dstname not overwriting dstname ... this flavor is certain not to emit a file exists error [with the obvious caviat - if it's write protected, your problem.] Much simpler than /y, .y or set copycmd fooness. Revision ChangesPath 1.39 +26 -40httpd-2.0/libhttpd.dsp Index: libhttpd.dsp === RCS file: /home/cvs/httpd-2.0/libhttpd.dsp,v retrieving revision 1.38 retrieving revision 1.39 diff -u -r1.38 -r1.39 --- libhttpd.dsp 17 Apr 2002 03:02:02 - 1.38 +++ libhttpd.dsp 24 May 2002 15:16:53 - 1.39 @@ -198,12 +198,11 @@ # PROP Ignore_Default_Tool 1 USERDEP__WIN32=.\include\os.h -# Begin Custom Build - Generating test_char.h +# Begin Custom Build - Generating test_char.h from gen_test_char.exe InputPath=.\server\gen_test_char.exe .\server\test_char.h : $(SOURCE) $(INTDIR) $(OUTDIR) .\server\gen_test_char.exe .\server\test_char.h - echo Generated test_char.h from gen_test_char.exe # End Custom Build @@ -211,12 +210,11 @@ # PROP Ignore_Default_Tool 1 USERDEP__WIN32=.\include\os.h -# Begin Custom Build - Generating test_char.h +# Begin Custom Build - Generating test_char.h from gen_test_char.exe InputPath=.\server\gen_test_char.exe .\server\test_char.h : $(SOURCE) $(INTDIR) $(OUTDIR) .\server\gen_test_char.exe .\server\test_char.h - echo Generated test_char.h from gen_test_char.exe # End Custom Build @@ -230,24 +228,22 @@ !IF $(CFG) == libhttpd - Win32 Release # PROP Ignore_Default_Tool 1 -# Begin Custom Build - Generating mod_core.h +# Begin Custom Build - Creating include/mod_core.h InputPath=.\modules\http\mod_core.h .\include\mod_core.h : $(SOURCE) $(INTDIR) $(OUTDIR) - xcopy /y .\modules\http\mod_core.h .\include - echo Created mod_core.h + type .\modules\http\mod_core.h .\include\mod_core.h # End Custom Build !ELSEIF $(CFG) == libhttpd - Win32 Debug # PROP Ignore_Default_Tool 1 -# Begin Custom Build - Generating mod_core.h +# Begin Custom Build - Creating include/mod_core.h InputPath=.\modules\http\mod_core.h .\include\mod_core.h : $(SOURCE) $(INTDIR) $(OUTDIR) - xcopy /y .\modules\http\mod_core.h .\include - echo Created mod_core.h + type .\modules\http\mod_core.h .\include\mod_core.h # End Custom Build @@ -261,24 +257,22 @@ !IF $(CFG) == libhttpd - Win32 Release # PROP Ignore_Default_Tool 1 -# Begin Custom Build - Generating mod_dav.h +# Begin Custom Build - Creating include/mod_dav.h InputPath=.\modules\dav\main\mod_dav.h .\include\mod_dav.h : $(SOURCE) $(INTDIR) $(OUTDIR) - xcopy /y .\modules\dav\main\mod_dav.h .\include - echo Created mod_dav.h + type .\modules\dav\main\mod_dav.h .\include\mod_dav.h # End Custom Build !ELSEIF $(CFG) == libhttpd - Win32 Debug # PROP Ignore_Default_Tool 1 -# Begin Custom Build - Generating mod_dav.h +# Begin Custom Build - Creating include/mod_dav.h InputPath=.\modules\dav\main\mod_dav.h .\include\mod_dav.h : $(SOURCE) $(INTDIR) $(OUTDIR) - xcopy /y .\modules\dav\main\mod_dav.h .\include - echo Created mod_dav.h + type .\modules\dav\main\mod_dav.h .\include\mod_dav.h # End Custom Build @@ -292,24 +286,22 @@ !IF $(CFG) == libhttpd - Win32 Release # PROP Ignore_Default_Tool 1 -# Begin Custom Build - Generating mod_proxy.h +# Begin Custom Build - Creating include/mod_proxy.h InputPath=.\modules\proxy\mod_proxy.h .\include\mod_proxy.h : $(SOURCE) $(INTDIR) $(OUTDIR) - xcopy /y .\modules\proxy\mod_proxy.h .\include - echo Created mod_proxy.h + type .\modules\proxy\mod_proxy.h .\include\mod_proxy.h # End Custom Build !ELSEIF $(CFG) == libhttpd - Win32 Debug # PROP Ignore_Default_Tool 1 -# Begin Custom Build - Generating mod_proxy.h +# Begin Custom Build - Creating include/mod_proxy.h InputPath=.\modules\proxy\mod_proxy.h .\include\mod_proxy.h : $(SOURCE) $(INTDIR) $(OUTDIR) - xcopy /y .\modules\proxy\mod_proxy.h .\include - echo Created mod_proxy.h + type .\modules\proxy\mod_proxy.h .\include\mod_proxy.h # End Custom Build @@ -323,24 +315,22 @@ !IF $(CFG) == libhttpd - Win32 Release # PROP Ignore_Default_Tool 1 -# Begin Custom Build - Generating mpm.h +# Begin Custom Build - Creating include/mpm.h
Re: [PATCH] simplified apachectl that passes through options tohttpd
On Fri, 24 May 2002, William A. Rowe, Jr. wrote: httpd -k start -DSSL Yes. How many other server modules [protocols especially, such as pop3 and so on] will beg the same. It's bogus. I agree. As another data point, I've seen a couple people confused by the startssl thing. They do: OK, let's start the server: apachectl start Now we have the server running, lets add ssl: apachectl startssl The options are confusing because they imply you are starting two different things, whereas in fact, you are starting the same thing with two different sets of options. Joshua.
Re: [PATCH] simplified apachectl that passes through options to httpd
On Fri, May 24, 2002 at 11:10:25AM -0500, William A. Rowe, Jr. wrote: Seriously, dump the IfDefine. For most cases these should really be IfModule mod_ssl.c entities instead anyways. Only the load module itself aught to be caught in an IfDefine SSL. I fail to see how setting up ssl in Apache 2.0 should differ from setting up mod_pop3, mod_mbox, mod_jk or any other module. I'd rather see us decouple loading of modules from enabling of modules, and then come up with a consistent way to do both. That way static modules are just implicitly loaded, DSOs can be optionally loaded with LoadModule, and it takes something else entirely to enable or disable*. *(The default could be to enable or disable, but a consistent way to override this at start-time would make it really clear to an admin how they can control this.) -aaron
Re: [PATCH] simplified apachectl that passes through options to httpd
William A. Rowe, Jr. [EMAIL PROTECTED] writes: At 10:52 AM 5/24/2002, you wrote: William A. Rowe, Jr. [EMAIL PROTECTED] writes: Can I ask WHY? -k has never supported anything but start/stop/restart and has always required a seperate -D SSL argument on Win32. I see the advantage of a simple apachectl doit verb that includes ssl. However, overloading -k start -D SSL with -k startssl seems outright silly. We can't argue back-compat here, -k didn't exist before. I think that this is your main point (please confirm): don't support httpd -k startssl, and instead force the user (or apachectl) to run httpd -k startssl -DSSL err... still a bit redundant, httpd -k start -DSSL should suffice [I'm pretty sure that's what you ment to ask :-] yep, I meant -k start -DSSL :) One issue that may affect your opinion: historic apachectl verbs are to be considered deprecated; the vision is that apachectl is just a wrapper script whose user interface is the same as httpd. Thinking long-term (e.g., Apache 2.1 or whatever), would you want the user to have to do httpd -k start -DSSL Yes. How many other server modules [protocols especially, such as pop3 and so on] will beg the same. It's bogus. If you configure your machine for SSL, then run it as SSL already!!! I'm +.6 on removing the httpd -k startssl hack already committed (my only reservation is due to my lack of interaction with the folks that actually use the startssl|sslstart thingie). Heck, I'm even fine with completely ditching the old apachectl verbs with 2.0.37 and imposing the un-onerous task on admins of converting to the httpd syntax. Once that happens the help text for httpd matches what apachectl will accept. For the moment I'll wait until I hear more opinions before deviating from the plan outlined in the original discussion. Thanks, -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: Tagging 2.0.37
I presume the -k patch... since apache -k start -n apache2 dumps the usage message. Forget about a Monday tag, folks. Late in the week, perhaps? Bill, before you run off, what is the ConfigArgs registry key about? There are four other boffo bugs I'd like to have a chance to look at before inflicting .37 on the world: 1. Fix apr_file_read() so that we don't crash on the first read in rotatelogs. Win32's implementation appears to have been borked in overeagerness to work around unusual read cases - we can't handle the simple ones. 2. Fix WinNT MPM to use apr_thread_create/apr_proc_create. The former is a simple fix, the later is required for folks who install Apache to a non- ASCII file path or who pass non-ASCII arguments on the command line. It's the last I18N hassle in Apache2. Essentially, I'm getting sick of us not eating our own dogfood ... those MS munchies may taste better, but where does it leave us? This is not a release show stopper 3. Fix thread setup/teardown on winnt mpm. We are using non-threadsafe threadcount incr/dec operations. I've seen it deadlock with six 'running threads' when no threads were left, and while it might be a quirk, we really need to address it. Looks easy enough to fix. I'll do it now. I have never seen a problem with the code as it is (though I agree it is not correct as is.) How do you recreate this? 4. Cruft in apr-util that exports undecorated names from apr_strmatch. Bill At 10:29 AM 5/24/2002, you wrote: HEAD will not start as a service on Windows. Not sure exactly when of what broke it. Bill - Original Message - From: Sander Striker [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, May 24, 2002 2:47 AM Subject: Tagging 2.0.37 Hi, What about tagging the tree on monday? Thoughts? Sander
ap_os_escape_pathn ?
ap_os_escape_path currently requires a pool argument to allocate the
string and does a strlen on it. wondering if we could do something like
the concept patch below, adding ap_os_escape_pathn which does not require
a pool and the path arg would be assumed to be allocated to the correct
size. would be a nice optimzation for perl land where string lengths are
always known and where the current ap_os_escape_path requires two copies,
the pool alloc and perl dup of the returned string. with something like
ap_os_escape_pathn we can avoid the strlen and the additional pool alloc.
could be useful elsewhere too i'm sure.
Index: server/util.c
===
RCS file: /home/cvs/httpd-2.0/server/util.c,v
retrieving revision 1.128
diff -u -r1.128 util.c
--- server/util.c 17 May 2002 11:11:37 - 1.128
+++ server/util.c 24 May 2002 16:33:40 -
-1632,6 +1632,12
AP_DECLARE(char *) ap_os_escape_path(apr_pool_t *p, const char *path, int partial)
{
char *copy = apr_palloc(p, 3 * strlen(path) + 3);
+return ap_os_escape_pathn(copy, partial);
+}
+
+AP_DECLARE(char *) ap_os_escape_pathn(char *copy, int partial)
+{
+char *path = copy;
const unsigned char *s = (const unsigned char *)path;
unsigned char *d = (unsigned char *)copy;
unsigned c;
Re: Is Apache Proxy Half-Duplex?
Ryan Bloom wrote: I tried to think through how to do this back in November, when I last touched the proxy. The easiest way to do this, is to add a new read mode to input filters, APR_READ_POLL. Each filter would be responsible for returning any data that it has if called in this mode. If none of the filters in the stack have any data, then the filter that has the socket must return the socket bucket, but it is allowed to keep a copy of the socket itself. The filter_poll call can then use apr_poll to determine which of the sockets have any data. This wouldn't be the cleanest code, but it should work. How about giving the read-from-filter-stack code the ability to read from more than one stack simultaneously? The basic idea would be that you would read from one or more stacks (where now you can only read from one stack). The read would return a brigade, and a variable to say which stack the brigade came from. It would be up to the calling code to decide intelligently on what to do with the brigade based on which stack it came from. This way a proxy might implement request pipelining. One or more requests would arrive via Apache's framework, and as they arrived the proxy could kick off possibly more than one request to possibly more than one backend. It would then read from the backends, and possibly buffer the content, before pipelining it in the correct sequence to the client. If the backends were slow, this could offer a significant performance improvement, as the backend would not have to wait till request A is finished before starting the generation of request B. Regards, Graham -- - [EMAIL PROTECTED]There's a moon over Bourbon Street tonight... smime.p7s Description: S/MIME Cryptographic Signature
Re: [PATCH] simplified apachectl that passes through options to httpd
At 11:30 AM 5/24/2002, Jeff Trawick wrote: William A. Rowe, Jr. [EMAIL PROTECTED] writes: err... still a bit redundant, httpd -k start -DSSL should suffice [I'm pretty sure that's what you ment to ask :-] yep, I meant -k start -DSSL :) One issue that may affect your opinion: historic apachectl verbs are to be considered deprecated; the vision is that apachectl is just a wrapper script whose user interface is the same as httpd. Thinking long-term (e.g., Apache 2.1 or whatever), would you want the user to have to do httpd -k start -DSSL Yes. How many other server modules [protocols especially, such as pop3 and so on] will beg the same. It's bogus. If you configure your machine for SSL, then run it as SSL already!!! I'm +.6 on removing the httpd -k startssl hack already committed (my only reservation is due to my lack of interaction with the folks that actually use the startssl|sslstart thingie). They don't [use the httpd thingie]... Heck, I'm even fine with completely ditching the old apachectl verbs with 2.0.37 and imposing the un-onerous task on admins of converting to the httpd syntax. Once that happens the help text for httpd matches what apachectl will accept. I'm not - apachectl has always been a convience thing. If we are making them change their conf to use httpd -k start without specifing -D SSL, I am still in favor of handling apachectl startssl [and all the silly flavors thereof.] I'm actually against pulling apachectl until version 2.1. Give them some time to adjust, provide some backwards compatibility for the present time. And in the meantime, don't break what apachectl already provides. Bill
Re: [PATCH] simplified apachectl that passes through options to httpd
At 11:18 AM 5/24/2002, you wrote: On Fri, May 24, 2002 at 11:10:25AM -0500, William A. Rowe, Jr. wrote: If you configure your machine for SSL, then run it as SSL already!!! Why are we trying to say you've installed and configured SSL, so now you have to turn it on explicitly everytime you start up. Which most will take as meaning I have apache2 installed, so now all I need to do is to startssl and everything will work. Simple: We have static and dynamic modules. Static modules can't turn off their LoadModule lines, so we can't use that to turn on and off the functionality in those modules. -DSSL is the runtime switch that mod_ssl uses to enable SSL functionality. That isn't a reason to create -k startssl to duplicate -k start -D SSL ...in fact, if you have a problem with not being able to disable a module in Apache2, then fix the essential problem, which is disabling modules. That was the feature 'broken' in Apache 2. And that still doesn't answer the question, why not simply; #Include conf/ssl.conf And let them uncomment it when they are good and ready. This shouldn't be a constantly toggled decision, either it's ready to run SSL or it's not. Bill
Re: Tagging 2.0.37
At 11:30 AM 5/24/2002, you wrote: I presume the -k patch... since apache -k start -n apache2 dumps the usage message. Forget about a Monday tag, folks. Late in the week, perhaps? Bill, before you run off, what is the ConfigArgs registry key about? Not going anywhere, overwhelmed with this weeks work-work which will end up throwing away my holiday weekend. Sorry if I didn't come across very friendly-like. On Windows, our command line argument is nothing but -k runservice. Not very interesting. We maintain our list of command line arguments in a registry key of type REG_MULTI_SZ, meaning each 'arg' is a null terminated part of the list of args [the end being double-null terminated, although since the entire char[] has a known length, it's redundant.] So -d is one argument, c:\Apache2 is the next arg, etc, and they look like this; -d\0c:\\Apache2\0-f\0c:\\Apache2\\conf\\httpd.conf\0 Or some such. Every time we use -k config we modify that array. When the SCM starts, we read and use those args, plus any arguments that were passed to the StartService() call (such as typing them in the 'optional parameters' field on the service property page, and clicking start.) There are four other boffo bugs I'd like to have a chance to look at before inflicting .37 on the world: 1. Fix apr_file_read() so that we don't crash on the first read in rotatelogs. Win32's implementation appears to have been borked in overeagerness to work around unusual read cases - we can't handle the simple ones. 2. Fix WinNT MPM to use apr_thread_create/apr_proc_create. The former is a simple fix, the later is required for folks who install Apache to a non- ASCII file path or who pass non-ASCII arguments on the command line. It's the last I18N hassle in Apache2. Essentially, I'm getting sick of us not eating our own dogfood ... those MS munchies may taste better, but where does it leave us? This is not a release show stopper For non-US directory names, it is. But I won't hold up .37 over this... although I'm likely to fix that code before attacking any issue except for 1. It would be part of the obvious fix for 3 as well... 3. Fix thread setup/teardown on winnt mpm. We are using non-threadsafe threadcount incr/dec operations. I've seen it deadlock with six 'running threads' when no threads were left, and while it might be a quirk, we really need to address it. Looks easy enough to fix. I'll do it now. I have never seen a problem with the code as it is (though I agree it is not correct as is.) How do you recreate this? In the devstudio 7.0 environment. As I say, I've tripped over it once after running httpd at least 4,000 times this week in new module development. It's a very small race. apr_thread_join would eliminate the bug entirely, c.f. number 2. 4. Cruft in apr-util that exports undecorated names from apr_strmatch. 5. I forgot a biggy on Allen's and other folks' lists - FIX the CWD! That's trickier in that we need to change CWD every time we hit a ServerRoot directive to do this right. I'll simply wrap that in an #ifdef WIN32 and we can wage the rest of this battle later, since noone in the Unix world sees a benefit in changing the cwd. I can't imagine that OS2 wouldn't benefit from the same behavior, though. Bill
Re: ap_os_escape_pathn ?
Doug MacEachern wrote:
ap_os_escape_path currently requires a pool argument to allocate the
string and does a strlen on it. wondering if we could do something like
the concept patch below, adding ap_os_escape_pathn which does not require
a pool and the path arg would be assumed to be allocated to the correct
size. would be a nice optimzation for perl land where string lengths are
always known and where the current ap_os_escape_path requires two copies,
the pool alloc and perl dup of the returned string. with something like
ap_os_escape_pathn we can avoid the strlen and the additional pool alloc.
could be useful elsewhere too i'm sure.
Index: server/util.c
===
RCS file: /home/cvs/httpd-2.0/server/util.c,v
retrieving revision 1.128
diff -u -r1.128 util.c
--- server/util.c 17 May 2002 11:11:37 - 1.128
+++ server/util.c 24 May 2002 16:33:40 -
-1632,6 +1632,12
AP_DECLARE(char *) ap_os_escape_path(apr_pool_t *p, const char *path, int partial)
{
char *copy = apr_palloc(p, 3 * strlen(path) + 3);
+return ap_os_escape_pathn(copy, partial);
Shouldn't that apr_palloc() now be an apr_pstrdup(), so that
apr_os_escape_pathn
doesn't have to work on an uninitialized buffer?
Other than that, +1 on the concept.
--Brian
RE: [PATCH] simplified apachectl that passes through options to httpd
From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]] At 11:18 AM 5/24/2002, you wrote: On Fri, May 24, 2002 at 11:10:25AM -0500, William A. Rowe, Jr. wrote: If you configure your machine for SSL, then run it as SSL already!!! Why are we trying to say you've installed and configured SSL, so now you have to turn it on explicitly everytime you start up. Which most will take as meaning I have apache2 installed, so now all I need to do is to startssl and everything will work. Simple: We have static and dynamic modules. Static modules can't turn off their LoadModule lines, so we can't use that to turn on and off the functionality in those modules. -DSSL is the runtime switch that mod_ssl uses to enable SSL functionality. That isn't a reason to create -k startssl to duplicate -k start -D SSL ...in fact, if you have a problem with not being able to disable a module in Apache2, then fix the essential problem, which is disabling modules. That was the feature 'broken' in Apache 2. I'm missing why that is considered broken. If you are compiling your own server, then you should only statically compile the modules that you want to use. If you are using a binary dist, then I don't know of any binary dists that use static modules instead of dynamic ones. Is there actually a case where somebody has wanted to be able to disable a module and been unable to? Ryan
Re: [PATCH] simplified apachectl that passes through options to httpd
William A. Rowe, Jr. [EMAIL PROTECTED] writes: Heck, I'm even fine with completely ditching the old apachectl verbs with 2.0.37 and imposing the un-onerous task on admins of converting to the httpd syntax. Once that happens the help text for httpd matches what apachectl will accept. I'm not - apachectl has always been a convience thing. by the way... with 2.0 on Unix, apachectl is a required thing to ensure that any environment variables (LD_LIBRARY_PATH and others) are set up properly If we are making them change their conf to use httpd -k start without specifing -D SSL, I am still in favor of handling apachectl startssl [and all the silly flavors thereof.] I'm actually against pulling apachectl until version 2.1. Give them some time to adjust, provide some backwards compatibility for the present time. And in the meantime, don't break what apachectl already provides. no plan to pull apachectl at all... the issue is when to stop mapping the old apachectl verbs onto httpd options... the user needs to know that all those options that can be passed to httpd can be passed to apachectl with no problem... the separate user interface for apachectl vs. httpd is potentially confusing... -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: [PATCH] simplified apachectl that passes through options to httpd
I think the old apachectl verbs should go. apachectl should source the envars and pass args unmodified to httpd. That's it. Bill - Original Message - From: Jeff Trawick [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, May 24, 2002 1:30 PM Subject: Re: [PATCH] simplified apachectl that passes through options to httpd William A. Rowe, Jr. [EMAIL PROTECTED] writes: Heck, I'm even fine with completely ditching the old apachectl verbs with 2.0.37 and imposing the un-onerous task on admins of converting to the httpd syntax. Once that happens the help text for httpd matches what apachectl will accept. I'm not - apachectl has always been a convience thing. by the way... with 2.0 on Unix, apachectl is a required thing to ensure that any environment variables (LD_LIBRARY_PATH and others) are set up properly If we are making them change their conf to use httpd -k start without specifing -D SSL, I am still in favor of handling apachectl startssl [and all the silly flavors thereof.] I'm actually against pulling apachectl until version 2.1. Give them some time to adjust, provide some backwards compatibility for the present time. And in the meantime, don't break what apachectl already provides. no plan to pull apachectl at all... the issue is when to stop mapping the old apachectl verbs onto httpd options... the user needs to know that all those options that can be passed to httpd can be passed to apachectl with no problem... the separate user interface for apachectl vs. httpd is potentially confusing... -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: [PATCH] simplified apachectl that passes through options
William A. Rowe, Jr. wrote: #Include conf/ssl.conf And let them uncomment it when they are good and ready. This shouldn't be a constantly toggled decision, either it's ready to run SSL or it's not. Bill Why require a config file change when it's s easy to define and determine behavior at start-up time, with the IfDef stuff... ( alright, alright, IfDefine :) )? -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
compile time issue
hi all, my apologies if this is not the appropriate forum. i have two compile/ link issues. [EMAIL PROTECTED] doesn't appear appropriate; most folks there aren't discussing compiler or linker isssues. mod_ssl.so doesn't seem to be linking the openssl libs, like lcrypto, so ldd -r is reporting missing symbols and the server fails in attempts to load the module at run time. i'm compiling 2.0.35 on a variety of solaris boxes, using all/ only Sun tools for building and linking. (/usr/ccs/bin, /opt/SUNWspro/, etc.). while looking for the solution to that problem, i ran into another link error. i'm consistently seeing problems with libtool: /bin/sh /vobs/WEB/src/apache2/src/srclib/apr/libtool --silent --mode=link cc -g -mt -DNO_DBM_REWRITEMAP-DSOLARIS2=6 -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT-I. -I/vobs/WEB/src/apache2/src/os/unix -I/vobs/WEB/src/apache2/src/server/mpm/worker -I/vobs/WEB/src/apache2/src/modules/http -I/vobs/WEB/src/apache2/src/modules/proxy -I/vobs/WEB/src/apache2/src/include -I/vobs/WEB/src/apache2/src/srclib/apr/include -I/vobs/WEB/src/apache2/src/srclib/apr-util/include -I/vobs/WEB/ssl_inst/include/openssl -I/vobs/WEB/ssl_inst/include -I/vobs/WEB/src/apache2/src/modules/dav/main -I/vobs/WEB/src/apache2/src/srclib/apr-util/include -I/vobs/WEB/src/apache2/src/srclib/apr-util/xml/expat/lib -export-dynamic -L/vobs/WEB/ssl_inst/lib -R/vobs/WEB/ssl_inst/lib -o httpd modules.lo -L/vobs/WEB/ssl_inst/lib -R/vobs/WEB/ssl_inst/lib modules/http/mod_http.la modules/mappers/mod_so.la server/mpm/worker/libworker.la server/libmain.la os/unix/libos.la /vobs/WEB/src/apache2/src/srclib/pcre/libpcre.la /vobs/WEB/src/apache2/src/srclib/apr-util/libaprutil.la /vobs/WEB/src/apache2/src/srclib/apr/libapr.la -lm -lsocket -lnsl -lresolv -ldl -lssl -lcrypto /vobs/WEB/src/apache2/src/srclib/apr-util/xml/expat/lib/libexpat.la ild: calling ld to finish link -- (internal error) ranlib_library() unexpected EL_UNINITIALIZED : modules/http/.libs/mod_http.al has anyone seen this problem? i am poking at libtool, etc. to attempt to solve this problem, but any help is greatly appreciated. cheers, andy
Re: Is Apache Proxy Half-Duplex?
Ryan Bloom wrote: From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Bill Stoddard wrote: This is a variation of the problem Aaron and I were interested in with CGI scripts (and directly related to an open PR against 2.0.36). Unfortunately, I think filters need some more work to make this possible. As Will said, we need to be able to poll/select on both the frontend and backend descriptors and do the right thing. I may be mistaken but I thought the proxy in 1.3 handled this correctly... The v1.3 proxy was always read request then read response, it never did these two simultaneously. Would the changes to the filters be that drastic? We would in theory just have to poll for incoming data (in either direction), then read bridages from the relevant filter stack...? No...? I tried to think through how to do this back in November, when I last touched the proxy. The easiest way to do this, is to add a new read mode to input filters, APR_READ_POLL. Each filter would be responsible for returning any data that it has if called in this mode. If none of the filters in the stack have any data, then the filter that has the socket must return the socket bucket, but it is allowed to keep a copy of the socket itself. The filter_poll call can then use apr_poll to determine which of the sockets have any data. This wouldn't be the cleanest code, but it should work. Seems to me that you really want a apr_poll equivalent that works on bucket brigades - that would make this clean, and could be quite elegant (IMO). Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: Is Apache Proxy Half-Duplex?
On Fri, May 24, 2002 at 07:20:34PM +0100, Ben Laurie wrote: Seems to me that you really want a apr_poll equivalent that works on bucket brigades - that would make this clean, and could be quite elegant (IMO). My thought as well: http:[EMAIL PROTECTED]%3E -aaron
Re: Is Apache Proxy Half-Duplex?
Ben Laurie [EMAIL PROTECTED] writes: Seems to me that you really want a apr_poll equivalent that works on bucket brigades - that would make this clean, and could be quite elegant (IMO). What seems useful (to me) is for apr_poll() to operate on a generic I/O handle (instead of apr_socket_t) and for the APR app to be able to retrieve the generic I/O handle from an APR socket or pipe or whatever. The bucket code could then be able to return a generic I/O handle corresponding to a bucket (extend it for brigades as well). (For some bucket types (e.g., heap) perhaps they always appear readable, or perhaps trying to retrieve the handle indicates that the operation is inappropriat.) -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: [PATCH] simplified apachectl that passes through options to httpd
On Fri, May 24, 2002 at 07:20:11AM -0400, Jeff Trawick wrote: google finds lots of hits for sslstart. The only hits for start-SSL I see so far are from the apachectl usage message. I've added support back in for the alternate spellings for the time being: sslstart|start-SSL) $HTTPD -k startssl ERROR=$? ;; FWIW, my intention in adding the -k feature was that the startssl would only be handled by apachectl - not by httpd itself. For startssl, apachectl would send in '-k start -DSSL'. I don't think it makes sense for httpd to recognize start-ssl (or its variants). That's something that apachectl can handle. The idea behind adding the -k feature to httpd on all platforms was that the start code was abstracted out of apachectl - not to support oddball invocation arguments. -- justin
Re: Is Apache Proxy Half-Duplex?
Jeff Trawick wrote: Ben Laurie [EMAIL PROTECTED] writes: Seems to me that you really want a apr_poll equivalent that works on bucket brigades - that would make this clean, and could be quite elegant (IMO). What seems useful (to me) is for apr_poll() to operate on a generic I/O handle (instead of apr_socket_t) and for the APR app to be able to retrieve the generic I/O handle from an APR socket or pipe or whatever. The bucket code could then be able to return a generic I/O handle corresponding to a bucket (extend it for brigades as well). (For some bucket types (e.g., heap) perhaps they always appear readable, or perhaps trying to retrieve the handle indicates that the operation is inappropriat.) Well, you may want that under the hood, but it clearly ain't right for bucket brigades, coz the brigade itself might have data ready. I suppose write brigades will have to say no at some point. Hmm. Non-trivial. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: [PATCH] For SSI include if statement with regexp
GAWLAS,JULIUS (HP-Cupertino,ex1) wrote: It appears that SSI if statement with regular expressions is broken: Committed, thanks! --Brian
Re: [PATCH] cruft in install-*
Joe Orton wrote:
The install- targets have {} \; left in the rm -rf invocation which
removes CVS directories, presumably a leftover from being a find -exec.
Thanks, I just committed the patch.
--Brian
Building apache_1.3.24 and httpd-2.0.36 under Mac OS 10.1.4?
Does anybody know how the redefinition of duplicate symbols problems are resolved under MacOS 10.1.4? Is it just a matter of not linking against the supplied regex libraries?
