Re: .la files for Apache DSOs
On Thu, Dec 13, 2001 at 09:14:55PM -0500, Jeff Trawick wrote: >... > We already do link DSOs with -module, though we also throw on > -export-dynamic as well, which doesn't seem appropriate. Well, some modules export symbols for use by other modules. Maybe that is why? Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: .la files for Apache DSOs
Greg Stein <[EMAIL PROTECTED]> writes: > On Thu, Dec 13, 2001 at 06:00:12PM -0500, Jeff Trawick wrote: > > Does anybody actually *want* these installed into prefix/modules by > > "make install" and "apxs -i"? > > > > If so, please speak up. I'd be curious about *why*. > > I say "no". As modules, they aren't intended for further linking. > > Note that we should probably be linking the modules with libtool's -module > switch. It would be interesting to see if that prevents the installation of > the .la file. We already do link DSOs with -module, though we also throw on -export-dynamic as well, which doesn't seem appropriate. -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: .la files for Apache DSOs
On Thu, Dec 13, 2001 at 05:57:54PM -0800, Greg Stein wrote: > On Thu, Dec 13, 2001 at 06:00:12PM -0500, Jeff Trawick wrote: > > Does anybody actually *want* these installed into prefix/modules by > > "make install" and "apxs -i"? > > > > If so, please speak up. I'd be curious about *why*. > > I say "no". As modules, they aren't intended for further linking. > > Note that we should probably be linking the modules with libtool's -module > switch. It would be interesting to see if that prevents the installation of > the .la file. AFAICT we do link DSOs with -module. -aaron
Re: cvs commit: httpd-2.0/modules/experimental config.m4
"Roy T. Fielding" <[EMAIL PROTECTED]> writes: > > Greg? I guess it is preferable to keep it in CPPFLAGS only > > temporarily (for the test) and put it in INCLUDES once we find that it > > works? > > Yes, unless it is required for later tests. Macros need to save and restore > any global make variables to avoid polluting later tests. Cool... I'll try to fix this up tonight. -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: .la files for Apache DSOs
On Thu, Dec 13, 2001 at 06:00:12PM -0500, Jeff Trawick wrote: > Does anybody actually *want* these installed into prefix/modules by > "make install" and "apxs -i"? > > If so, please speak up. I'd be curious about *why*. I say "no". As modules, they aren't intended for further linking. Note that we should probably be linking the modules with libtool's -module switch. It would be interesting to see if that prevents the installation of the .la file. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: Is there any reason
On Thu, Dec 13, 2001 at 03:10:29PM -0600, William A. Rowe, Jr. wrote: > to waste cycles on the insert_filters hook if we don't run a request? > Should this simply get pushed from ap_process_request_internal() into > ap_invoke_handler() as the first part of the handler-execution phase? Seems reasonable to me. The intent was always to run that hook right before the handling starts. It would let everything get set up in the request_rec, and then people can make choices about whether to insert filters. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: cvs commit: httpd-2.0/modules/experimental config.m4
On Mon, Dec 10, 2001 at 07:08:30AM -0500, Jeff Trawick wrote: > Sascha Schumann <[EMAIL PROTECTED]> writes: > > > On Mon, 10 Dec 2001, Greg Stein wrote: > > > > > I don't understand why an include doesn't go onto the INCLUDES variable. Why > > > the shift? > > > > I suppose that the include directive is immediately needed > > for an autoconf cpp check. Autoconf calls the preprocessor > > with CPPFLAGS, not INCLUDES, and thus it is correct to add > > the include directive to the former variable. > > on the nose! autodetection was failing... > > Greg? I guess it is preferable to keep it in CPPFLAGS only > temporarily (for the test) and put it in INCLUDES once we find that it > works? Yes, unless it is required for later tests. Macros need to save and restore any global make variables to avoid polluting later tests. Roy
.la files for Apache DSOs
Does anybody actually *want* these installed into prefix/modules by "make install" and "apxs -i"? If so, please speak up. I'd be curious about *why*. -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: Considering the Default Handler and Subrequests
From: "Ryan Bloom" <[EMAIL PROTECTED]> Sent: Thursday, December 13, 2001 4:00 PM > If you want to make this work for the most modules possible, create a single > model that all modules must implement, and make that perform the best > that it can. That's exactly what I'm saying ... 1.3 had two flavors, by-name and by-pattern, and threw them all into one heap. Do we agree we can ignore the by-pattern cruft, add a handler_name arg to an ap_register_handler() fn, and invoke by exact match one specific handler? The other case (by-pattern) should have been treated seperately in the first place. Rather than waiting for the handler phase, the module either gets invoked by an explicit AddHandler/SetHandler directive, or the very sophisticated module can play games in the fixups phase, changing the handler string to itself when it is 'interested' in taking the request. Is this an agreeable pattern to everyone? Bill
Re: Considering the Default Handler and Subrequests
On Thursday 13 December 2001 01:44 pm, Greg Ames wrote: > Ryan Bloom wrote: > > I still think the handler_fn function is overkill. The performance of > > Apache 1.3 wasn't bad, because we did sane string compares, making sure > > that the lengths were equal before doing a full strcmp. > > You're right, 1.3 was faster than the way we do it now. But we could do > better still. > > I was thinking of something like a hash or a trie search for exact > matches on r->handler. But then OtherBill got me thinking that if a > module decided that it could serve the request in some earlier phase, it > ought to be able to do something to latch on to the handler phase and > eliminate most of the searching altogether. The problem with this, as I just explained to Bill on the phone, is that you are providing two mechanisms to do the same thing. You are trying to solve a problem in the core by making it harder to write a performant module. The harder it is to write a performant module, the fewer people who will do so. If you want to make this work for the most modules possible, create a single model that all modules must implement, and make that perform the best that it can. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: Considering the Default Handler and Subrequests
From: "Greg Ames" <[EMAIL PROTECTED]> Sent: Thursday, December 13, 2001 3:44 PM > Ryan Bloom wrote: > > > I still think the handler_fn function is overkill. The performance of Apache 1.3 > > wasn't bad, because we did sane string compares, making sure that the > > lengths were equal before doing a full strcmp. > > You're right, 1.3 was faster than the way we do it now. But we could do > better still. > > I was thinking of something like a hash or a trie search for exact > matches on r->handler. But then OtherBill got me thinking that if a > module decided that it could serve the request in some earlier phase, it > ought to be able to do something to latch on to the handler phase and > eliminate most of the searching altogether. If we do implement this with a hash, to a static handler name (drop this whole idea of pattern matches), then I think the one solution makes the most sense. Leave it a string for the common case, and those few that are setting themselves up based on wildcards can simply set the r->handler string. Bill
Re: Considering the Default Handler and Subrequests
Ryan Bloom wrote: > > I still think the handler_fn function is overkill. The performance of Apache 1.3 > wasn't bad, because we did sane string compares, making sure that the > lengths were equal before doing a full strcmp. You're right, 1.3 was faster than the way we do it now. But we could do better still. I was thinking of something like a hash or a trie search for exact matches on r->handler. But then OtherBill got me thinking that if a module decided that it could serve the request in some earlier phase, it ought to be able to do something to latch on to the handler phase and eliminate most of the searching altogether. Greg
RE: problem running 2.0.28 as Win2k service (was 2.0.18)
Any other thoughts on this one? It's going to become important very soon that I be able to run my own build as a service. Thanks. - Dave -Original Message- From: Dave Seidel [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 12, 2001 3:29 PM To: William A. Rowe, Jr.; [EMAIL PROTECTED] Subject: RE: problem running 2.0.28 as Win2k service (was 2.0.18) OK, I installed the August 2001 Platform SDK from the November MSDN issue (if there's a later one, they haven't sent it, and the website is down). Made sure to install the Visual Studio integration, etc. Wiped out httpd-2_0_28, unzipped a fresh copy, rebuilt. Same problem. Then I reinstalled VS6SP5, rebuilt from scratch again. Same problem. -Original Message- From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 12, 2001 12:38 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: problem running 2.0.28 as Win2k service (was 2.0.18) From: "Dave Seidel" <[EMAIL PROTECTED]> Sent: Wednesday, December 12, 2001 9:10 AM > FYI, I did my local build using VC 6.0, using the InstallBin target in the > IDE, using all the project files as they came from the zip archive. Dave, if you grab a recent PlatformSDK from Microsoft's site, and install it into your DevStudio, does it work? That will help us break apart those two issues, since distributions are always built with a more-recent PlatformSDK, and VC6.0 SP5.
Re: Considering the Default Handler and Subrequests
On Thursday 13 December 2001 01:07 pm, William A. Rowe, Jr. wrote: > Blending Ryan's and Greg's observations with my own... > > It probably makes more sense to register the supported handlers (one > call per handler/name) with a handler name to follow the 1.3 convention. > For all simple cases, this is probably best. > > Only modules with interesting characteristics (not foo-bar names, but > rather */* matches, such as a .gif file processing engine or something > like that) would want to try grabbing handler_fn along the request. I still think the handler_fn function is overkill. The performance of Apache 1.3 wasn't bad, because we did sane string compares, making sure that the lengths were equal before doing a full strcmp. Using the handler_fn is going to make writing a module VERY complex, because we will have multiple ways to solve the same problem. Either we use a handler_fn, or we use a handler name, not both. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Is there any reason
to waste cycles on the insert_filters hook if we don't run a request? Should this simply get pushed from ap_process_request_internal() into ap_invoke_handler() as the first part of the handler-execution phase?
Re: Considering the Default Handler and Subrequests
Blending Ryan's and Greg's observations with my own... It probably makes more sense to register the supported handlers (one call per handler/name) with a handler name to follow the 1.3 convention. For all simple cases, this is probably best. Only modules with interesting characteristics (not foo-bar names, but rather */* matches, such as a .gif file processing engine or something like that) would want to try grabbing handler_fn along the request. Bill
Re: Considering the Default Handler and Subrequests
From: "Greg Ames" <[EMAIL PROTECTED]> Sent: Thursday, December 13, 2001 1:55 PM > "William A. Rowe, Jr." wrote: > > > Second, autoindex should be a generator [handler]. mod_dir should _NOT_. I >spelled > > out the reasons for that on 2001.12.02. > > OK, peace. But since we were talking about how to drive handlers more > efficiently, we need to think about the harder cases. One of them will > be how to deal with multiple handlers who will accept the same > r->handler value. :) We have a number of cases like this. I'd believe that the simplest way to handle them is to address the handler first in the translation phase (if the request maps to a non-filesystem uri) or then in the type checker or fixup based on the content (which is what the old system did 90% of the time anyways.) Let's look at the full list of Apache handlers; default_handler The fallback case, assigned in fixups if nobody else gloms onto a filesystem request (where r->finfo.filetype != NULL). Or it could be the product of handler_fn != NULL, and left at that. file_cache_handler, handle_map_file Are identified in the translate_names phase (file found) and could be overridden with SetHandler/AddHandler in the type-checker phase. Not really a generator, but these are alternates to the default (plain file) cases. isapi_handler, cgi_handler, cgid_handler, asis_handler, imap_handler These can be claimed in the type-checker phase (SetHandler/AddHandler or by-content-type.) All of these are truly handlers because they do very unique things with otherwise plain files. display_info, status_handler Are identified by the location_walk phase (SetHandler or error condition) and really are generators. ssl_hook_Handler A generator I suspect doesn't need to be, we should be allowed to error out earlier. If this is not possible, it's easily identified very early on. [Just an "It's Broke, don't send plain requests on an SSL port!" response.] autoindex_handler Can be claimed in the fixups phase if nobody else claims it, it is really a generator. dir_handler, redirect_handler We shouldn't have to get this far, we should be able to return the redirect back in the fixups phase, as I've proposed for mod_dir. This allows us to print some pretty href in the autoindex listing that would save us a roundtrip from the client, potentially. proxy_handler Which is a real handler, and is easily identified up front, at least by the fixups phase even on internal proxy redirection. action_handler A really tricky little beast, no? If you want one to debate, here it is :) So there's the recap. I assert that we can decide exactly which handler aught to take a request no later than the fixups phase. Comments? Bill
RE: 64 bit compiles of mod_ssl & OpenSSL?
Yep.. we've tried it out on HPUX on the IA-64 boxes - and verified that "make test" works :-). -Madhu -Original Message- From: Bill Stoddard [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 13, 2001 12:12 PM To: [EMAIL PROTECTED] Subject: 64 bit compiles of mod_ssl & OpenSSL? Several folks have reported success serving pages with 64 bit compiles of Apache 2.0 (AIX and Solaris as I recall). Has anyone had similar success with 64 bit compiles of OpenSSL? Bill
64 bit compiles of mod_ssl & OpenSSL?
Several folks have reported success serving pages with 64 bit compiles of Apache 2.0 (AIX and Solaris as I recall). Has anyone had similar success with 64 bit compiles of OpenSSL? Bill
Re: Considering the Default Handler and Subrequests
"William A. Rowe, Jr." wrote: > > > If we resolve the ->handler up front, why not > > > provide a ->handler_fn member that skips the entire handler() hook walk? > > > > The implementation would be interesting. Consider mod_dir and > > mod_autoindex. Both can deal with DIR_MAGIC_TYPE, and both could be > > present or absent. But when both are present, the handler topological > > sort rules must be respected so that handle_dir runs first. How do you > > propose dealing with that? And what about the few handlers that support > > fuzzy matches? > > Couple of bits. If we declare handler_fn identically to a hook_handler callback, > then we can maintain the semantics. A handler could raise it's hand, but later > DECLINE. If it DECLINEs, or handler_fn is NULL, then we proceed with the usual > walk. > > Second, autoindex should be a generator [handler]. mod_dir should _NOT_. I spelled > out the reasons for that on 2001.12.02. OK, peace. But since we were talking about how to drive handlers more efficiently, we need to think about the harder cases. One of them will be how to deal with multiple handlers who will accept the same r->handler value. Greg
Re: Windows cgi problem
From: "Jeff Trawick" <[EMAIL PROTECTED]> Sent: Thursday, December 13, 2001 1:17 PM > what if we had a long-running-daemon attribute and a non-interactive > attribute (yeah, please come up with better names): > > long-running-daemonnon-interactive > > Win32child doesn't get window child doesn't get window > Unix all the forks, setsid, whatever no-op Child must have window, or pipes are broken on Windows. The difference is that we need to create the worker child window detached, and hidden. The CGI and other execs within the child should occur attached in it's own (hidden) window, and the parent window remains quiet amidst the storm :) Guess we aren't doing that right now, I'll try to jump on it. Bill
Re: Considering the Default Handler and Subrequests
From: "Ryan Bloom" <[EMAIL PROTECTED]> Sent: Thursday, December 13, 2001 1:22 PM > On Thursday 13 December 2001 11:05 am, William A. Rowe, Jr. wrote: > > > > Couple of bits. If we declare handler_fn identically to a hook_handler > > callback, then we can maintain the semantics. A handler could raise it's > > hand, but later DECLINE. If it DECLINEs, or handler_fn is NULL, then we > > proceed with the usual walk. > > Why don't we go back to the original model, where a handler function is > associated with a handler-name, and the core just calls the correct one? And reintroduce more strcasecmps and fnmatches :-? Let's drop handler and leave nothing but handler_fn if you like. Very deterministic. It's bold, it's brash, it's hip :) Seriously, when on earth was it strictly associated with a modules name? both mod_mmap_static and core registered for "*/*", and core got it if mmap didn't have it (DECLINED.) It's always been a hook. Bill
309 sleeping - sbwait 0:02 0.00% 0.00% httpd
Hi all! I´m having my websites working very slow... when TOP see what happens: 312 processes: 2 running, 309 sleeping, 1 zombie --->> See, I have 309 process sleeping A lot of this appears to me: 38409 nobody2 0 18344K 2776K sbwait 0:02 0.00% 0.00% httpd --->> SBWAIT??? Just waiting, but not working?? Could be this my problem?? How do I solve it?? Tks all!! Att, Daniel
Re: Help writing a filter
Dwayne Miller wrote: > Where would I find examples and docs for writing a filter that could... Read Ryan's series: === http://www.onlamp.com/pub/a/apache/2001/08/23/apache_2.html http://www.onlamp.com/pub/a/apache/2001/09/13/apache_2.html http://www.onlamp.com/pub/a/apache/2001/09/20/apache_2.html There are attached samples: === http://www.onlamp.com/apache/2001/09/13/examples/mod_swap.c http://www.ntrnet.net/~rbb/mod_apachecon.c (the last one can't be followed from the link in the article; There is a broken link at onLamp, so you must use the URL I gave here) A reference about filters (!): == http://groups.yahoo.com/group/new-httpd/message/26052 Also, try to dig in http://httpd.apache.org/docs-2.0/developer/ And, the BEST resourse for filters, is... ...you guessed! The sources, of course! -- Eli Marmor [EMAIL PROTECTED] CTO, Founder Netmask (El-Mar) Internet Technologies Ltd. __ Tel.: +972-9-766-1020 8 Yad-Harutzim St. Fax.: +972-9-766-1314 P.O.B. 7004 Mobile: +972-50-23-7338 Kfar-Saba 44641, Israel
Re: Windows cgi problem
From: "Ryan Bloom" <[EMAIL PROTECTED]> Sent: Thursday, December 13, 2001 1:09 PM > On Thursday 13 December 2001 11:02 am, Allan Edwards wrote: > > This might also be a problem on unix but I haven't tested. > > When cgi's are launched a window sometimes pops up, same for > > mod_include "exec cgi". Is there a reason we are not > > launching the cgi as a detached process? > > You definately do not want to detach on Unix, because if you do, the > CGI script will end up forking three times. Actually, something smells wrong here. It sounds like we are possibly detaching, and thus activating a console. We should have a console, it should be hidden, and we should behave ourselves (exactly as unix does.) Bill
RE: Windows cgi problem
> > mod_include "exec cgi". Is there a reason we are not > > launching the cgi as a detached process? > > Yes. They are broken for all 16 bit CGIs. 16 bit CGI's seem to be broken at the moment anyway. > We need some mechansim to > pass off the fact that we've tested, and it is a good, well behaved > 32 bit app. Because 16bitters invoke their own console thunk, they > fail to ever clean up pipes correctly, hanging the connections. Yes, I presume we must be doing something like this in 1.3 since 1.3 works for bot 16 & 32 bit apps Allan
Re: Considering the Default Handler and Subrequests
On Thursday 13 December 2001 11:05 am, William A. Rowe, Jr. wrote: > From: "Greg Ames" <[EMAIL PROTECTED]> > Sent: Thursday, December 13, 2001 12:49 PM > > > "William A. Rowe, Jr." wrote: > > > . Hooks are _not_ the fastest things in the world, especially with the > > > strcmps around ->handler going on. > > > > Amen! This one has been bugging me for a long time. It won't show up > > clearly in a profiler, because the CPU cycles are spread over all the > > handlers. We are polluting the instruction cache by touching a lot of > > separate chunks of code that only return DECLINED. > > > > > If we resolve the ->handler up front, why not > > > provide a ->handler_fn member that skips the entire handler() hook > > > walk? > > > > The implementation would be interesting. Consider mod_dir and > > mod_autoindex. Both can deal with DIR_MAGIC_TYPE, and both could be > > present or absent. But when both are present, the handler topological > > sort rules must be respected so that handle_dir runs first. How do you > > propose dealing with that? And what about the few handlers that support > > fuzzy matches? > > Couple of bits. If we declare handler_fn identically to a hook_handler > callback, then we can maintain the semantics. A handler could raise it's > hand, but later DECLINE. If it DECLINEs, or handler_fn is NULL, then we > proceed with the usual walk. Why don't we go back to the original model, where a handler function is associated with a handler-name, and the core just calls the correct one? Ryan > > Second, autoindex should be a generator [handler]. mod_dir should _NOT_. > I spelled out the reasons for that on 2001.12.02. It is part of the wide > bogosity of dir requests 'slipping through' into autoindex. mod_dir could > only be considered a handler if it returns an external redirect, any other > response it provides in an internal fixup that should happen in fixups. If > you try my mod_dir/autoindex patches of late 2001.12.02 [when I got around > to fixing the implications of mod_dir as a fixup in mod_autoindex] you > should discover it runs fine. Had changed mod_dir it to use our > ap_fast_internal_redirect, so it will uncover more bugs than mod_negotation > does alone. > > Bill -- __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: Windows cgi problem
Ryan Bloom <[EMAIL PROTECTED]> writes: > On Thursday 13 December 2001 11:02 am, Allan Edwards wrote: > > This might also be a problem on unix but I haven't tested. > > When cgi's are launched a window sometimes pops up, same for > > mod_include "exec cgi". Is there a reason we are not > > launching the cgi as a detached process? > > You definately do not want to detach on Unix, because if you do, the > CGI script will end up forking three times. yep... beyond that is the issue that detached on Win32 and detached on Unix really mean different things... what if we had a long-running-daemon attribute and a non-interactive attribute (yeah, please come up with better names): long-running-daemonnon-interactive Win32child doesn't get window child doesn't get window Unix all the forks, setsid, whatever no-op (just a rough sketch, but you get the picture) -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: Windows cgi problem
From: "Allan Edwards" <[EMAIL PROTECTED]> Sent: Thursday, December 13, 2001 1:02 PM > This might also be a problem on unix but I haven't tested. > When cgi's are launched a window sometimes pops up, same for > mod_include "exec cgi". Is there a reason we are not > launching the cgi as a detached process? Yes. They are broken for all 16 bit CGIs. We need some mechansim to pass off the fact that we've tested, and it is a good, well behaved 32 bit app. Because 16bitters invoke their own console thunk, they fail to ever clean up pipes correctly, hanging the connections. Bill
Re: Considering the Default Handler and Subrequests
From: "Greg Ames" <[EMAIL PROTECTED]> Sent: Thursday, December 13, 2001 12:49 PM > "William A. Rowe, Jr." wrote: > > > . Hooks are _not_ the fastest things in the world, especially with the strcmps > > around ->handler going on. > > Amen! This one has been bugging me for a long time. It won't show up > clearly in a profiler, because the CPU cycles are spread over all the > handlers. We are polluting the instruction cache by touching a lot of > separate chunks of code that only return DECLINED. > > > If we resolve the ->handler up front, why not > > provide a ->handler_fn member that skips the entire handler() hook walk? > > The implementation would be interesting. Consider mod_dir and > mod_autoindex. Both can deal with DIR_MAGIC_TYPE, and both could be > present or absent. But when both are present, the handler topological > sort rules must be respected so that handle_dir runs first. How do you > propose dealing with that? And what about the few handlers that support > fuzzy matches? Couple of bits. If we declare handler_fn identically to a hook_handler callback, then we can maintain the semantics. A handler could raise it's hand, but later DECLINE. If it DECLINEs, or handler_fn is NULL, then we proceed with the usual walk. Second, autoindex should be a generator [handler]. mod_dir should _NOT_. I spelled out the reasons for that on 2001.12.02. It is part of the wide bogosity of dir requests 'slipping through' into autoindex. mod_dir could only be considered a handler if it returns an external redirect, any other response it provides in an internal fixup that should happen in fixups. If you try my mod_dir/autoindex patches of late 2001.12.02 [when I got around to fixing the implications of mod_dir as a fixup in mod_autoindex] you should discover it runs fine. Had changed mod_dir it to use our ap_fast_internal_redirect, so it will uncover more bugs than mod_negotation does alone. Bill
Re: Windows cgi problem
On Thursday 13 December 2001 11:02 am, Allan Edwards wrote: > This might also be a problem on unix but I haven't tested. > When cgi's are launched a window sometimes pops up, same for > mod_include "exec cgi". Is there a reason we are not > launching the cgi as a detached process? You definately do not want to detach on Unix, because if you do, the CGI script will end up forking three times. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Windows cgi problem
This might also be a problem on unix but I haven't tested.
When cgi's are launched a window sometimes pops up, same for
mod_include "exec cgi". Is there a reason we are not
launching the cgi as a detached process?
Index: mod_cgi.c
===
RCS file: /home/cvs/httpd-2.0/modules/generators/mod_cgi.c,v
retrieving revision 1.113
diff -u -d -b -r1.113 mod_cgi.c
--- mod_cgi.c 2001/12/13 17:22:20 1.113
+++ mod_cgi.c 2001/12/13 18:49:03
@@ -446,6 +446,7 @@
"couldn't set child process attributes: %s", r->filename);
}
else {
+apr_procattr_detach_set(procattr, 1);
procnew = apr_pcalloc(p, sizeof(*procnew));
if (e_info->prog_type == RUN_AS_SSI) {
SPLIT_AND_PASS_PRETAG_BUCKETS(*(e_info->bb), e_info->ctx, e_info->next,
rc);
Allan
RE: cvs commit: httpd-2.0/docs/manual/mod mod_cgi.html mod_cgid.html core.html
> From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]] > > From: "Joshua Slive" <[EMAIL PROTECTED]> > Sent: Thursday, December 13, 2001 12:31 PM > > Just a loopy thought: Would it be useful to make the syntax > > AcceptPathInfo On|Off|Default > > where > > AcceptPathInfo Default > > was the same as not having the directive at all (a no-op in the > code)? This > > would seem to make the tri-state nature a little clearer. > > Would that be Default, or Unset? > AcceptFilter in 1.3 has "default", but it doesn't really matter to me. Joshua.
Re: Considering the Default Handler and Subrequests
"William A. Rowe, Jr." wrote: > . Hooks are _not_ the fastest things in the world, especially with the strcmps > around ->handler going on. Amen! This one has been bugging me for a long time. It won't show up clearly in a profiler, because the CPU cycles are spread over all the handlers. We are polluting the instruction cache by touching a lot of separate chunks of code that only return DECLINED. > If we resolve the ->handler up front, why not > provide a ->handler_fn member that skips the entire handler() hook walk? The implementation would be interesting. Consider mod_dir and mod_autoindex. Both can deal with DIR_MAGIC_TYPE, and both could be present or absent. But when both are present, the handler topological sort rules must be respected so that handle_dir runs first. How do you propose dealing with that? And what about the few handlers that support fuzzy matches? Greg
Re: cvs commit: httpd-2.0/docs/manual/mod mod_cgi.html mod_cgid.html core.html
From: "Joshua Slive" <[EMAIL PROTECTED]> Sent: Thursday, December 13, 2001 12:31 PM > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > wrowe 01/12/13 10:19:22 > > > > Modified:docs/manual/mod mod_cgi.html mod_cgid.html core.html > > Log: > > A little loopy commit. Refer mod_cgid users to the mod_cgi docs for > > extra info, document the AcceptPathInfo impact in the > > PATH_INFO comments > > of mod_cgi, and document it's configuration in core. > > Just a loopy thought: Would it be useful to make the syntax > AcceptPathInfo On|Off|Default > where > AcceptPathInfo Default > was the same as not having the directive at all (a no-op in the code)? This > would seem to make the tri-state nature a little clearer. Would that be Default, or Unset?
RE: cvs commit: httpd-2.0/docs/manual/mod mod_cgi.html mod_cgid.html core.html
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > wrowe 01/12/13 10:19:22 > > Modified:docs/manual/mod mod_cgi.html mod_cgid.html core.html > Log: > A little loopy commit. Refer mod_cgid users to the mod_cgi docs for > extra info, document the AcceptPathInfo impact in the > PATH_INFO comments > of mod_cgi, and document it's configuration in core. Just a loopy thought: Would it be useful to make the syntax AcceptPathInfo On|Off|Default where AcceptPathInfo Default was the same as not having the directive at all (a no-op in the code)? This would seem to make the tri-state nature a little clearer. Joshua.
Help writing a filter
Where would I find examples and docs for writing a filter that could... examine and potentially re-write form variables posted by client examine and potentially re-write url variables posted by client create some new cgi variables and publish them do all of this before any other request processing module is run
RE: cvs commit: httpd-2.0/server core.c
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > wrowe 01/12/12 21:49:28 > > Modified:server core.c > Log: > Now all should be well. AcceptPathInfo on will give us a > document with > path_info served from the core handler. Any filters can then > manipulate > all the usual CGI envvars [as proven with this little excerpt with a > document... Cool. Thanks for fixing that Bill. Joshua.
Re: cvs commit: httpd-2.0/include http_core.h
[EMAIL PROTECTED] writes: > trawick 01/12/13 05:15:56 > > Modified:include http_core.h > Log: > hack up core_dir_config so that server/core.c compiles again OtherBill probably wants to check the data type and provide appropriate commentary. > > Index: http_core.h > === > RCS file: /home/cvs/httpd-2.0/include/http_core.h,v > retrieving revision 1.53 > retrieving revision 1.54 > diff -u -r1.53 -r1.54 > --- http_core.h 2001/11/18 02:57:12 1.53 > +++ http_core.h 2001/12/13 13:15:56 1.54 > @@ -447,6 +447,7 @@ >const char *handler; /* forced with SetHandler */ >const char *output_filters; /* forced with SetOutputFilters */ >const char *input_filters; /* forced with SetInputFilters */ > +int accept_path_info; >} core_dir_config; -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: cvs commit: httpd-2.0/support Makefile.in
Greg Stein <[EMAIL PROTECTED]> writes: > On Wed, Dec 12, 2001 at 07:39:55PM -, [EMAIL PROTECTED] wrote: > > trawick 01/12/12 11:39:55 > > > > Modified:.acinclude.m4 configure.in > >support Makefile.in > > Log: > > change Apache/apr/apr-util to use run-time linking on AIX > > > > currently, a kludge (-uXML_Parse) is needed to get a reference to expat > > in the Apache executable programs; I think this is related to the fact > > that expat libtool is getting generated a little differently than apr > > libtool and is choosing to build a different flavor of shared library > > If you patch the build in apr-util/xml/expat/, then I'll synchronize your > changes with the main Expat source control. That is: we can get the "right > flavor" in whatever fashion you choose. cool.. (assuming somebody can figure out what is happening :) ) -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
