Re: authz / authn and mod_auth_ldap
--On Friday, January 17, 2003 9:59 AM +0200 Graham Leggett <[EMAIL PROTECTED]> wrote: If I were to change mod_auth_ldap to use the new authz/authn system in v2.1, I have to split mod_auth_ldap into mod_authn_ldap (the is-password-correct part) and mod_authz_ldap (group-membership part). Am I correct? No, you don't *have* to split them into different modules. One module could register for both authn/authz providers. The only reason we split was because their wasn't a lot of shared code between the other auth modules. I think mod_auth_ldap has a lot of shared code in its authn/authz split. Perhaps a mod_auth_ldap core module that exports the basic LDAP functionality, then a mod_authn_ldap and mod_authz_ldap module that does the direct auth code? I dunno. -- justin
Re: bug in mod_cgi (sends 200 instead of 500)
On Fri, Jan 17, 2003 at 04:36:58PM +1100, Stas Bekman wrote: > Consider this mod_cgi script: > > #!/usr/bin/perl -w > print "Content-type: text/plain\n\n"; > print no_such_func(); > print "Shouldn't be printed"; > > httpd.conf: > ScriptAlias /cgi-bin/ "/home/httpd/2.0/perl/" > > The error is correctly logged: > > [Fri Jan 17 16:31:03 2003] [error] [client 127.0.0.1] Undefined subroutine > &main::no_such_func called at /home/httpd/2.0/perl/500.pl line 6. > > Though the client gets the response code 200! That's correct behaviour :) If the CGI outputs valid headers and a blank newline, then it's considered valid. Any subsequent errors or return status within the CGI have no effect. -- [EMAIL PROTECTED]PubKey: [EMAIL PROTECTED] Web: http://devnull.redbrick.dcu.ie/
Re: bug in mod_cgi (sends 200 instead of 500)
--On Friday, January 17, 2003 4:36 PM +1100 Stas Bekman <[EMAIL PROTECTED]> wrote: Consider this mod_cgi script: # !/usr/bin/perl -w print "Content-type: text/plain\n\n"; print no_such_func(); print "Shouldn't be printed"; httpd.conf: ScriptAlias /cgi-bin/ "/home/httpd/2.0/perl/" The error is correctly logged: [Fri Jan 17 16:31:03 2003] [error] [client 127.0.0.1] Undefined subroutine &main::no_such_func called at /home/httpd/2.0/perl/500.pl line 6. Though the client gets the response code 200! Why do you think that would be a 500? I don't think merely writing stuff out to stderr or returning with an non-zero status code shouldn't be grounds for a 500. -- justin
Re: authz / authn and mod_auth_ldap
Justin Erenkrantz wrote: No, you don't *have* to split them into different modules. One module could register for both authn/authz providers. The only reason we split was because their wasn't a lot of shared code between the other auth modules. I think mod_auth_ldap has a lot of shared code in its authn/authz split. All (or most) of the shared code is in mod_ldap already. It should be relatively easy to split mod_auth_ldap into mod_authn_ldap and mod_authz_ldap. Regards, Graham -- - [EMAIL PROTECTED] "There's a moon over Bourbon Street tonight..."
Re: authz / authn and mod_auth_ldap
> All (or most) of the shared code is in mod_ldap already. It should be > relatively easy to split mod_auth_ldap into mod_authn_ldap and > mod_authz_ldap. Perhaps we need to go into the terminilogy that modules which have no handlers (except init, etc) or no directives are called something like 'lib_ldap' or libmod. I would certainly split N and Z in the case of ldap; as I've seen useful cases in the fields where one or the other was merged with other means; such as RSA SecurID and 'fail over' static lists in case LDAP (or evil things like fragile SideMinder) where down. Dw.
Re: authz / authn and mod_auth_ldap
+1 for splitting auth_ldap into authz/authn. We will be releasing our mod_edir module that provides an alternative authorization service for auth_ldap. It relies on mod_auth_ldap for authentication and then enforces access control through mod_edir. It it currently implemented by adding an "edir-user" option in place of "valid-user" to the requires directive. Splitting auth_ldap into authz/authn would allow us to completely replace the authorization services with eDirectory. Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com >>> [EMAIL PROTECTED] Friday, January 17, 2003 2:02:17 AM >>> --On Friday, January 17, 2003 9:59 AM +0200 Graham Leggett <[EMAIL PROTECTED]> wrote: > If I were to change mod_auth_ldap to use the new authz/authn system > in v2.1, I have to split mod_auth_ldap into mod_authn_ldap (the > is-password-correct part) and mod_authz_ldap (group-membership > part). Am I correct? No, you don't *have* to split them into different modules. One module could register for both authn/authz providers. The only reason we split was because their wasn't a lot of shared code between the other auth modules. I think mod_auth_ldap has a lot of shared code in its authn/authz split. Perhaps a mod_auth_ldap core module that exports the basic LDAP functionality, then a mod_authn_ldap and mod_authz_ldap module that does the direct auth code? I dunno. -- justin
RE: bug in mod_cgi (sends 200 instead of 500)
That is correct behaviour to send a 200 since the HTTP headers are complete. It's always been this way. I am working on a modification to mod_cgi so a module can register a special output_and_stderr filter, parse stderr, and can send a 500 if it deems necessary. > -Original Message- > From: Stas Bekman [SMTP:[EMAIL PROTECTED]] > Sent: Thursday, January 16, 2003 11:37 PM > To: [EMAIL PROTECTED] > Subject: bug in mod_cgi (sends 200 instead of 500) > > Consider this mod_cgi script: > > #!/usr/bin/perl -w > print "Content-type: text/plain\n\n"; > print no_such_func(); > print "Shouldn't be printed"; > > httpd.conf: > ScriptAlias /cgi-bin/ "/home/httpd/2.0/perl/" > > The error is correctly logged: > > [Fri Jan 17 16:31:03 2003] [error] [client 127.0.0.1] Undefined subroutine > &main::no_such_func called at /home/httpd/2.0/perl/500.pl line 6. > > Though the client gets the response code 200! > > HTTP/1.1 200 OK > Date: Fri, 17 Jan 2003 05:33:12 GMT > Server: Apache/2.1.0-dev (Unix) mod_perl/1.99_09-dev Perl/v5.9.0 > mod_ssl/2.1.0-dev OpenSSL/0.9.6g DAV/2 > Connection: close > Content-Type: text/plain; charset=ISO-8859-1 > > __ > 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 >
truncated filenames on nagoya
Hi all, while someone has take care that the main directory at: http://www.apache.org/dist/httpd/ displays all filenames complete, there are almost all longer filenames of the binaries truncated; f.e.: http://nagoya.apache.org/mirror/httpd/binaries/linux/ http://nagoya.apache.org/mirror/httpd/binaries/netware/ http://nagoya.apache.org/mirror/httpd/binaries/win32/ can someone please commit a .htaccess into http://nagoya.apache.org/mirror/httpd/binaries/ to correct this issue for all subdirs; or is it preferred that every platform maintainer does this self for his dir?? Guenter.
Re: authz / authn and mod_auth_ldap
Graham Leggett wrote: Justin Erenkrantz wrote: No, you don't *have* to split them into different modules. One module could register for both authn/authz providers. The only reason we split was because their wasn't a lot of shared code between the other auth modules. I think mod_auth_ldap has a lot of shared code in its authn/authz split. All (or most) of the shared code is in mod_ldap already. It should be relatively easy to split mod_auth_ldap into mod_authn_ldap and mod_authz_ldap. Why would we want to split the module into two pieces? What benefit to users does it provide and do those benefits (whatever they are) outweigh the additional complexity of knowing when/whether you need to load each piece? Bill
Re: [1.3 PATCH] enhance some trace messages
+1
At 9:42 AM -0500 1/16/03, Jeff Trawick wrote:
>
>I can certainly understand that :) Here is a new patch along those lines.
>
>Index: main/http_main.c
>===
>RCS file: /home/cvs/apache-1.3/src/main/http_main.c,v
>retrieving revision 1.599
>diff -u -r1.599 http_main.c
>--- main/http_main.c 9 Jan 2003 09:24:10 - 1.599
>+++ main/http_main.c 16 Jan 2003 14:36:38 -
>@@ -3555,7 +3555,7 @@
> }
>
> #if defined(TCP_NODELAY) && !defined(MPE) && !defined(TPF)
>-static void sock_disable_nagle(int s)
>+static void sock_disable_nagle(int s, struct sockaddr_in *sin_client)
> {
> /* The Nagle algorithm says that we should delay sending partial
> * packets in hopes of getting more data. We don't want to do
>@@ -3573,13 +3573,20 @@
> #ifdef NETWARE
> errno = WSAGetLastError();
> #endif
>- ap_log_error(APLOG_MARK, APLOG_WARNING, server_conf,
>- "setsockopt: (TCP_NODELAY)");
>+if (sin_client) {
>+ap_log_error(APLOG_MARK, APLOG_WARNING, server_conf,
>+ "setsockopt: (TCP_NODELAY), client %pA probably "
>+ "dropped the connection", &sin_client->sin_addr);
>+}
>+else {
>+ap_log_error(APLOG_MARK, APLOG_WARNING, server_conf,
>+ "setsockopt: (TCP_NODELAY)");
>+}
> }
> }
>
> #else
>-#define sock_disable_nagle(s) /* NOOP */
>+#define sock_disable_nagle(s, c) /* NOOP */
> #endif
>
> static int make_sock(pool *p, const struct sockaddr_in *server)
>@@ -3663,7 +3670,7 @@
> }
> #endif
>
>-sock_disable_nagle(s);
>+sock_disable_nagle(s, NULL);
> sock_enable_linger(s);
>
> /*
>@@ -4513,11 +4520,14 @@
>
> clen = sizeof(sa_server);
> if (getsockname(csd, &sa_server, &clen) < 0) {
>- ap_log_error(APLOG_MARK, APLOG_ERR, server_conf, "getsockname");
>+ ap_log_error(APLOG_MARK, APLOG_ERR, server_conf,
>+ "getsockname, client %pA probably dropped the "
>+ "connection",
>+ &((struct sockaddr_in *)&sa_client)->sin_addr);
> continue;
> }
>
>- sock_disable_nagle(csd);
>+ sock_disable_nagle(csd, (struct sockaddr_in *)&sa_client);
>
> (void) ap_update_child_status(my_child_num, SERVER_BUSY_READ,
> (request_rec *) NULL);
>@@ -5884,7 +5894,7 @@
> memset(&sa_client, '\0', sizeof(sa_client));
> }
>
>- sock_disable_nagle(csd);
>+ sock_disable_nagle(csd, (struct sockaddr_in *)&sa_client);
>
> (void) ap_update_child_status(child_num, SERVER_BUSY_READ,
> (request_rec *) NULL);
--
===
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
wanted: snapshots from apr-iconv
Hi, is it possible that we can get also snapshots of apr-iconv at: http://cvs.apache.org/snapshots/ ?? and in addition it would be fine if we could have both the stable and the dev tree as snapshots; currently since teh trees where splitted there's only a snapshot of the 2.1 dev tree... Guenter.
TCPMUX and Apache
Is it possible to run Apache on a named port such as http://www.moo.org:cow with TCPMUX? _ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail
Re: authz / authn and mod_auth_ldap
Hi, I read the discussion for few messages, i am not an apache developper, so i will speak as a user. IMHO, Splitting into two modules will make auth more complex. actually, it's not really easy to setup, and the documentation is not always up to date. regards Matthieu Bill Stoddard wrote: Graham Leggett wrote: Justin Erenkrantz wrote: No, you don't *have* to split them into different modules. One module could register for both authn/authz providers. The only reason we split was because their wasn't a lot of shared code between the other auth modules. I think mod_auth_ldap has a lot of shared code in its authn/authz split. All (or most) of the shared code is in mod_ldap already. It should be relatively easy to split mod_auth_ldap into mod_authn_ldap and mod_authz_ldap. Why would we want to split the module into two pieces? What benefit to users does it provide and do those benefits (whatever they are) outweigh the additional complexity of knowing when/whether you need to load each piece? Bill _ Envie de discuter en "live" avec vos amis ? Télécharger MSN Messenger http://www.ifrance.com/_reloc/m la 1ère messagerie instantanée de France _ GRAND JEU SMS : Pour gagner un NOKIA 7650, envoyez le mot IF au 61321 (prix d'un SMS + 0.35 euro). Un SMS vous dira si vous avez gagné. Règlement : http://www.ifrance.com/_reloc/sign.sms
Re: cvs commit: httpd-2.0/include ap_release.h
you definitely da bomb! [EMAIL PROTECTED] wrote: striker 2003/01/17 11:04:37 Modified:include Tag: APACHE_2_0_BRANCH ap_release.h Log: Bump for the tag.
RE: cvs commit: httpd-2.0/include ap_release.h
> From: Jeff Trawick [mailto:[EMAIL PROTECTED]] > Sent: Friday, January 17, 2003 8:11 PM > you definitely da bomb! Good or bad? ;) Sander > [EMAIL PROTECTED] wrote: > >> striker 2003/01/17 11:04:37 >> >> Modified:include Tag: APACHE_2_0_BRANCH ap_release.h >> Log: >> Bump for the tag.
Re: cvs commit: httpd-2.0/include ap_release.h
Sander Striker wrote: >From: Jeff Trawick [mailto:[EMAIL PROTECTED]] >Sent: Friday, January 17, 2003 8:11 PM >you definitely da bomb! Good or bad? ;) I meant it as a compliment, of course! (everything I know I learned from my 11-year-old daughter, so beware)
Re: cvs commit: httpd-2.0/include ap_release.h
Tagged "Januari 17?" :-) - Dmitri. On 17 Jan 2003 [EMAIL PROTECTED] wrote: > striker 2003/01/17 11:07:31 > > Modified:.Tag: APACHE_2_0_BRANCH STATUS >include Tag: APACHE_2_0_BRANCH ap_release.h > Log: > Bump after the tag. > > Revision ChangesPath > No revision > > > No revision > > > 1.751.2.41 +3 -2 httpd-2.0/STATUS > > Index: STATUS > === > RCS file: /home/cvs/httpd-2.0/STATUS,v > retrieving revision 1.751.2.40 > retrieving revision 1.751.2.41 > diff -u -r1.751.2.40 -r1.751.2.41 > --- STATUS 17 Jan 2003 18:52:44 - 1.751.2.40 > +++ STATUS 17 Jan 2003 19:07:30 - 1.751.2.41 > @@ -3,7 +3,8 @@ > >Release: > > -2.0.44 : in development > +2.0.45 : in development > +2.0.44 : tagged Januari 17, 2003. >2.0.43 : released October 3, 2002 as GA. >2.0.42 : released September 24, 2002 as GA. >2.0.41 : rolled September 16, 2002. not released. > > > > No revision > > > No revision > > > 1.77.2.2 +1 -1 httpd-2.0/include/ap_release.h > > Index: ap_release.h > === > RCS file: /home/cvs/httpd-2.0/include/ap_release.h,v > retrieving revision 1.77.2.1 > retrieving revision 1.77.2.2 > diff -u -r1.77.2.1 -r1.77.2.2 > --- ap_release.h17 Jan 2003 19:04:37 - 1.77.2.1 > +++ ap_release.h17 Jan 2003 19:07:31 - 1.77.2.2 > @@ -75,7 +75,7 @@ >#define AP_SERVER_BASEPRODUCT "Apache" >#define AP_SERVER_MAJORVERSION "2" >#define AP_SERVER_MINORVERSION "0" > -#define AP_SERVER_PATCHLEVEL "44" > +#define AP_SERVER_PATCHLEVEL "45-dev" >#define AP_SERVER_MINORREVISION AP_SERVER_MAJORVERSION "." AP_SERVER_MINORVERSION >#define AP_SERVER_BASEREVISION AP_SERVER_MINORREVISION "." AP_SERVER_PATCHLEVEL >#define AP_SERVER_BASEVERSION AP_SERVER_BASEPRODUCT "/" AP_SERVER_BASEREVISION > > > >
RE: cvs commit: httpd-2.0/include ap_release.h
> From: Dmitri Tikhonov [mailto:[EMAIL PROTECTED]] > Sent: Friday, January 17, 2003 8:53 PM > Tagged "Januari 17?" :-) *sigh* Yeah, that's how you spell it in The Netherlands. Fix comming up, although I might aswell roll it first... Sander
Tagged and Rolled 2.0.44
Hi, I just tagged and rolled 2.0.44. Tarballs are up at: http://httpd.apache.org/dev/dist/ Please cast your votes accordingly. I did the roll with libtool 1.4.2. If this is a problem, let me know, I'll upgrade my libtool to 1.4.3 and re-roll ASAP. Thanks, Sander
Re: Tagged the tree, one more time
Sander Striker wrote: I just tagged STRIKER_2_0_44_PRE3. I think this is going to be our .44. It would be nice to give it one more day on daedalus and get some +1s on it. +1 for release as 2.0.44, and thanks for your efforts. Greg
Re: bug in mod_cgi (sends 200 instead of 500)
Justin Erenkrantz wrote: --On Friday, January 17, 2003 4:36 PM +1100 Stas Bekman <[EMAIL PROTECTED]> wrote: Consider this mod_cgi script: # !/usr/bin/perl -w print "Content-type: text/plain\n\n"; print no_such_func(); print "Shouldn't be printed"; httpd.conf: ScriptAlias /cgi-bin/ "/home/httpd/2.0/perl/" The error is correctly logged: [Fri Jan 17 16:31:03 2003] [error] [client 127.0.0.1] Undefined subroutine &main::no_such_func called at /home/httpd/2.0/perl/500.pl line 6. Though the client gets the response code 200! Why do you think that would be a 500? > I don't think merely writing stuff out to stderr or returning with an non-zero status code shouldn't be grounds for a 500. -- justin Because the script has failed. Not because it has written something to stderr. But because the exec's return status is not 0. % perl -lwe 'no_such_func();' || echo $? Undefined subroutine &main::no_such_func called at -e line 1. 255 It shows that I haven't run mod_cgi for ages. I was just used to having this as a failure (500) under mod_perl. Any reason for not checking the return status? __ 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: [emerg] (28)No space left on device: Couldn't create accept lock
I am also getting this error. Do you know how to solve the problem? thanks, Miha --- In [EMAIL PROTECTED], Jeff Trawick <[EMAIL PROTECTED]> wrote: > Stas Bekman <[EMAIL PROTECTED]> writes: > > > After starting the server for many times I've received: > > > > [Tue Jan 14 15:55:36 2003] [emerg] (28)No space left on device: > > Couldn't create accept lock > > > > I figured out that it was the ipc device that run out of space on the > > allocated segment, because I had encountered this problem before. > > > > Is it possible to make that error message more descriptive, so users > > won't have to wonder what device the error message is talking about? > > (shields up :) ) > > The best compromise may be for APR to have an error code that is used > just for when SysV IPC returns ENOSPC. Techies will want to know that > the kernel returned ENOSPC, but just representing it as ENOSPC like we > do today results in an error description that doesn't help users. > > -- > Jeff Trawick | [EMAIL PROTECTED] > Born in Roswell... married an alien...
Re: Tagged and Rolled 2.0.44
* Sander Striker wrote: > I just tagged and rolled 2.0.44. Tarballs are up at: > > http://httpd.apache.org/dev/dist/ > > Please cast your votes accordingly. Didn't test it at the moment, but I guess, the CHANGES file should not contain 2.0.45 changes... ;-) nd -- If God intended people to be naked, they would be born that way. -- Oscar Wilde
Re: Tagged and Rolled 2.0.44
On Fri, Jan 17, 2003 at 09:32:51PM +0100, Sander Striker wrote: > Hi, > > I just tagged and rolled 2.0.44. Tarballs are up at: > > http://httpd.apache.org/dev/dist/ > > Please cast your votes accordingly. > > > I did the roll with libtool 1.4.2. If this is a problem, > let me know, I'll upgrade my libtool to 1.4.3 and re-roll > ASAP. Isn't 1.4.3 needed for MacOS compatibility, and maybe one of those fool IBM operating systems? And isn't it about frickin' time to just change the code to require autoconf 2.5x and libtool 1.4.x ? "make sure you roll with libtool FOO" Screw it. Make it require that you do that. If we don't want all developers to be subject to that requirement, then we make make the distribution script (the tarball roller) enforce the stronger check. (in Subversion, the build check looks for autoconf 2.5x and libtool 1.4.x, but the dist.sh script enforces libtool 1.4.3) Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: bug in mod_cgi (sends 200 instead of 500)
* Stas Bekman wrote: > It shows that I haven't run mod_cgi for ages. I was just used to having > this as a failure (500) under mod_perl. Any reason for not checking the > return status? hmm, performance? memory usage? What about a script that throws out a lot of data (say, 1 MB, multiplied with $number_of_instances) and then dies with "could not read last record from file"? How does mod_perl handle such cases? nd -- > [...] weiß jemand zufällig, was der Tag DIV ausgeschrieben bedeutet? DIVerses. Benannt nach all dem unstrukturierten Zeug, was die Leute da so reinpacken und dann absolut positionieren ... -- Florian Hartig und Lars Kasper in dciwam
Re: [emerg] (28)No space left on device: Couldn't create accept lock
manaay wrote: I am also getting this error. Do you know how to solve the problem? You don't tell which OS you are on. On linux 'ipcs' lists the semaphores and shared mem segments. which you can delete with 'ipcrm', e.g. % ipcs -- Semaphore Arrays keysemid owner perms nsems 0x 4325376stas 6001 ... % ipcrm -s 4325376 I don't know of a command to remove all semaphores at once, other than doing some scripting. This works for me: % ipcs | perl -ne '/^0x (\d+) / && `ipcrm -s $1`' Since I start and kill the server many times (probably when running from gdb) I get many dead semaphores pretty quickly :( __ 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: bug in mod_cgi (sends 200 instead of 500)
André Malo wrote: * Stas Bekman wrote: It shows that I haven't run mod_cgi for ages. I was just used to having this as a failure (500) under mod_perl. Any reason for not checking the return status? hmm, performance? memory usage? What about a script that throws out a lot of data (say, 1 MB, multiplied with $number_of_instances) and then dies with "could not read last record from file"? How does mod_perl handle such cases? OK, I see that my question was improper. 200 is indeed OK, because you don't buffer up the data before you know the return status. What I was missing is the error message attached to the end of the normal output to indicate that there was a problem (better late than never). e.g. the following script: #!/usr/bin/perl -w print "Content-type: text/plain\n\n"; print "Should be printed"; print no_such_func(); print "Shouldn't be printed"; Under mod_cgi, it'll print only: Should be printed whereas under mod_perl, it'll print: Should be printed Server error! ... and the rest of the error message. because mod_perl checks the return status and sends the error message through if there is one. This gives an indication to the developer that something went wrong. Unfortunately too few developers remember to check the error_log file for errors. Indeed apache-1.3's mod_cgi behaves identicallly to 2.0's mod_cgi. __ 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
Access request_rec from a connection filter in Apache 2.0
Hello, I have a connection filter of type AP_FTYPE_NETWORK which gets called just before the core output filter. I have placed it here to get at (read only) the raw output of the server for a given request. The problem that I am facing is that when my filter callback gets called, there is no reference available to the current request (f->r == NULL). All I get is a reference to the connection (f->c != NULL). I would like to have some sort of "request context" within my filter callback, primarily so that I can access ap_get_module_config(f->r->request_config, &m) and retrieve data that I set in a previous stage (like the fixup stage). I'm not too sure of the best way to do this, or if it even makes sense given the structure of Apache 2.0 filtering. But basically, what I'm looking for is to access to the raw output of the server (full Headers and Body) and be able to associate that content (or bucket brigade) with a request_rec from within a filter callback. I've done the following as a hack: ap_set_module_config(r->conn_config, &my_module, r); right in the fixup phase after determining if I should care about this request. And then, within the filter, I do a: request_rec *r = ap_get_module_config(c->conn_config, &my_module); This works for, but I'm pretty sure that there would be problems with this. Any thoughts?? Thanks for the help. Mike C.
Re: bug in mod_cgi (sends 200 instead of 500)
* Stas Bekman wrote:
> What I was missing is the error message attached to the end of the normal
> output to indicate that there was a problem (better late than never).
>
> e.g. the following script:
>
> #!/usr/bin/perl -w
> print "Content-type: text/plain\n\n";
> print "Should be printed";
> print no_such_func();
> print "Shouldn't be printed";
Well, that can be easily decided by the developer:
(it's not exactly the same, but does the trick in nearly all cases)
#!/usr/bin/perl -w
use CGI::Carp 'fatalsToBrowser';
print "Content-type: text/plain\n\n";
print "Should be printed";
print no_such_func();
print "Shouldn't be printed";
:-)
nd
--
$_=q?tvc!uif)%*|#Bopuifs!A`#~tvc!Xibu)%*|qsjou#Kvtu!A`#~tvc!KBQI!)*|~
tvc!ifmm)%*|#Qfsm!A`#~tvc!jt)%*|(Ibdlfs(~ # What the hell is JAPH? ;
@_=split/\s\s+#/;$_=(join''=>map{chr(ord( # André Malo ;
$_)-1)}split//=>$_[0]).$_[1];s s.*s$_see; # http://www.perlig.de/ ;
Re: cvs commit: httpd-2.0 Makefile.win
At 08:24 PM 1/17/2003, [EMAIL PROTECTED] wrote:
>wrowe 2003/01/17 18:24:46
>
> Modified:.Tag: APACHE_2_0_BRANCH Makefile.win
> Log:
>Damned... this was broken but, since most of us build from .dsp files,
>it was never noted. I intend to package this patch into the Win32 .zip
>source distribution, by virtue that all of the .mak files (what triggers
>this build line anyways) are only generated once preparing the win32 .zip
>source package.
Well, after generating the .mak/.dep/.rc files for Win32 and having applied
this one-liner to Makefile.win, I've zipped up the package and have it going
up to dadelus right now.
Note that anyone checking out the APACHE_2_0_44 tag has no .mak files
in the first place, so this build problem isn't triggered. The Makefile.win
will build directly from the Apache.dsw project workspace *unless* it finds
.mak files lying around.
The .mak files only directly benefit our VC5.0 users.
If folks feel this is grounds for scrapping .44 and moving to .45 then fine,
I have no issues with that. But I also don't feel that we must do so,
given that the entire .mak schema is a manual, after-the-tag process.
Bill
--- Makefile.win 15 Jan 2003 15:13:35 - 1.120.2.4
+++ Makefile.win 18 Jan 2003 02:24:46 - 1.120.2.5
@@ -233,12 +233,12 @@
$(MAKE) $(MAKEOPT) -f mod_charset_lite.mak CFG="mod_charset_lite - Win32
$(LONG)" RECURSE=0 $(CTARGET)
$(MAKE) $(MAKEOPT) -f mod_mem_cache.mak CFG="mod_mem_cache - Win32 $(LONG)"
RECURSE=0 $(CTARGET)
$(MAKE) $(MAKEOPT) -f mod_disk_cache.mak CFG="mod_disk_cache - Win32 $(LONG)"
RECURSE=0 $(CTARGET)
- $(MAKE) $(MAKEOPT) -f mod_ext_filter.mak CFG="mod_ext_filter - Win32 $(LONG)"
RECURSE=0 $(CTARGET)
cd ..\..
cd modules\filters
!IF EXIST("srclib\zlib")
$(MAKE) $(MAKEOPT) -f mod_deflate.mak CFG="mod_deflate - Win32 $(LONG)"
RECURSE=0 $(CTARGET)
!ENDIF
+ $(MAKE) $(MAKEOPT) -f mod_ext_filter.mak CFG="mod_ext_filter - Win32 $(LONG)"
RECURSE=0 $(CTARGET)
$(MAKE) $(MAKEOPT) -f mod_include.mak CFG="mod_include - Win32 $(LONG)"
RECURSE=0 $(CTARGET)
cd ..\..
cd modules\generators
