Re: Mitigating XSS in the mod_perl API
- Original Message - From: "Thomas Eibner" <[EMAIL PROTECTED]> Subject: Re: Mitigating XSS in the mod_perl API > On Mon, Jan 27, 2003 at 02:45:13PM +, Matt Sergeant wrote: > > On Mon, 27 Jan 2003, Thomas Eibner wrote: > > > > > So, because a programmer doesn't check the validity of the input he gets > > > it's a bug that should be fixed in Apache? Maybe someone should make > > > sure that the same thing can't happen with allowing CGI input going > > > straight into a form.. oh wait. > > > I don't see anyone from dev@httpd wanting to "fix" this bogus error when > > > it's really just doing what the programmer wants to do (when he is not > > > validating the input). > > > > The programmer wants to output a header. If he accidentally tries to > > output something thats not a header he actually ends up outputting body. > > Thats a bug. > > I can see the validity of your point, but it's still a programmer error. > The same thing could happen if you did this as plain CGI and outputted > something you weren't supposed to do. Right - except that if he's outputting it raw from CGI, we can assume that he knows what he's doing, while if he's using a function which is DESIGNED to output a header (which should NOT have an extra \n), that's obviously either a mistake or a malicious misuse. Neither of which warrants the function doing what it was asked to do. If the programmer wants to intentionally bypass the "header_out" rule, he should bypass some more and send the headers himself. I know that sounds weak, but I've got to say that I side with Matt here. Issac - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mitigating XSS in the mod_perl API
Here's the patch in case anyone is interested in applying it to their own
apache. I think there's probably a bug in that \n might not always be the
right thing to look for (CRLF issues), so please send me corrections ;-)
I haven't actually run this, so it might not work. But to quote Lord
Flashheart: "That's the kind of guy I am". :-)
Index: src/main/http_protocol.c
===
RCS file: /home/cvs/apache-1.3/src/main/http_protocol.c,v
retrieving revision 1.329
diff -u -r1.329 http_protocol.c
--- src/main/http_protocol.c3 Oct 2002 20:51:53 - 1.329
+++ src/main/http_protocol.c28 Jan 2003 11:26:37 -
@@ -1561,8 +1561,16 @@
const char *fieldname,
const char *fieldval)
{
+char *line_feed;
if (strcasecmp(fieldname, "ETag") == 0) {
if (ap_table_get(r->notes, "no-etag") != NULL) {
+return 1;
+}
+}
+if ((line_feed = strchr(fieldval, '\n')) != NULL) {
+/* don't allow any headers with line feeds in them */
+if (line_feed[1] != ' ' && line_feed[1] != '\t') {
+/* unless it's a continuation */
return 1;
}
}
--
<:->get a SMart net
Spam trap - do not mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mitigating XSS in the mod_perl API
Matt Sergeant wrote: Here's the patch in case anyone is interested in applying it to their own apache. I think there's probably a bug in that \n might not always be the right thing to look for (CRLF issues), so please send me corrections ;-) I'm not a C guy, but there are some constants in httpd.h that may help with CRLF portability stuff (see below). and just for my interest, can you explain the continuation logic? I don't get it :) --Geoff #ifndef CHARSET_EBCDIC #define LF 10 #define CR 13 #define CRLF "\015\012" #define OS_ASC(c) (c) #else /* CHARSET_EBCDIC */ #include "ap_ebcdic.h" /* OSD_POSIX uses the EBCDIC charset. The transition ASCII->EBCDIC is done in * the buff package (bread/bputs/bwrite), so everywhere else, we use * "native EBCDIC" CR and NL characters. These are therefore defined as * '\r' and '\n'. * NB: this is not the whole truth - sometimes \015 and \012 are contained * in literal (EBCDIC!) strings, so these are not converted but passed. */ #define CR '\r' #define LF '\n' #define CRLF "\r\n" #define OS_ASC(c) (os_toascii[c]) #endif /* CHARSET_EBCDIC */ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mitigating XSS in the mod_perl API
On Tue, Jan 28, 2003 at 01:08:28PM +0200, Issac Goldstand wrote: > - Original Message - > From: "Thomas Eibner" <[EMAIL PROTECTED]> > Subject: Re: Mitigating XSS in the mod_perl API > > > > On Mon, Jan 27, 2003 at 02:45:13PM +, Matt Sergeant wrote: > > > On Mon, 27 Jan 2003, Thomas Eibner wrote: > > > > > > > So, because a programmer doesn't check the validity of the input he > gets > > > > it's a bug that should be fixed in Apache? Maybe someone should make > > > > sure that the same thing can't happen with allowing CGI input going > > > > straight into a form.. oh wait. > > > > I don't see anyone from dev@httpd wanting to "fix" this bogus error > when > > > > it's really just doing what the programmer wants to do (when he is not > > > > validating the input). > > > > > > The programmer wants to output a header. If he accidentally tries to > > > output something thats not a header he actually ends up outputting body. > > > Thats a bug. > > > > I can see the validity of your point, but it's still a programmer error. > > The same thing could happen if you did this as plain CGI and outputted > > something you weren't supposed to do. > > Right - except that if he's outputting it raw from CGI, we can assume that > he knows what he's doing, while if he's using a function which is DESIGNED > to output a header (which should NOT have an extra \n), that's obviously > either a mistake or a malicious misuse. Neither of which warrants the > function doing what it was asked to do. If the programmer wants to > intentionally bypass the "header_out" rule, he should bypass some more and > send the headers himself. I know that sounds weak, but I've got to say that > I side with Matt here. Yes, that sounds very weak. To me it sounds like Matt doesn't know what he is doing if he's passing RAW input from a client directly into something. I know it sounds harsh and I'm not trying to degrade Matt as I have great respect for the work he is and has been doing for Perl and mod_perl in general, but from looking at use.perl it does indeed sound like Matt just figured this out 1) All this really boils down to is that the stuff that operates on r->headers_out and r->err_headers_out shouldn't allow for line endings to be in there, but directly putting input from the client in there is even worse IMHO. And I don't really think it's designed to output a header. Tables where used because it made it easy to implement (I assume), and it's only in mod_perl and not the C api that there are specific functions for adding to r->headers_out and r->err_headers_out, so ultimatively if anything should deal with it, it's either the mod_perl functions OR as Matt has submitted around line 1570 (in my non-up-to-date cvs copy) in http_protocol.c, and yes, I do believe it's the right thing to do so you can't output \n nor \r's in headers. And if you would have to bypass the header_out rule you would have to write to the socket yourself and somehow make sure apache doesn't send the headers, right? (I'm not so sure about this part :-)) 1) http://use.perl.org/~Matts/journal/10161 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mitigating XSS in the mod_perl API
On Tue, Jan 28, 2003 at 11:30:18AM +, Matt Sergeant wrote:
> Here's the patch in case anyone is interested in applying it to their own
> apache. I think there's probably a bug in that \n might not always be the
> right thing to look for (CRLF issues), so please send me corrections ;-)
>
> I haven't actually run this, so it might not work. But to quote Lord
> Flashheart: "That's the kind of guy I am". :-)
>
> Index: src/main/http_protocol.c
> ===
> RCS file: /home/cvs/apache-1.3/src/main/http_protocol.c,v
> retrieving revision 1.329
> diff -u -r1.329 http_protocol.c
> --- src/main/http_protocol.c3 Oct 2002 20:51:53 - 1.329
> +++ src/main/http_protocol.c28 Jan 2003 11:26:37 -
> @@ -1561,8 +1561,16 @@
> const char *fieldname,
> const char *fieldval)
> {
> +char *line_feed;
> if (strcasecmp(fieldname, "ETag") == 0) {
> if (ap_table_get(r->notes, "no-etag") != NULL) {
> +return 1;
> +}
> +}
> +if ((line_feed = strchr(fieldval, '\n')) != NULL) {
> +/* don't allow any headers with line feeds in them */
> +if (line_feed[1] != ' ' && line_feed[1] != '\t') {
> +/* unless it's a continuation */
> return 1;
> }
> }
I'm wondering if it's not smarter to go over fieldval and at the first
occourance of a \r or \n terminate the line there? I think there will
be more problems by just not outputting the headers in the first place.
Something like:
--- http_protocol.c.old Mon Jan 27 09:45:57 2003
+++ http_protocol.c Tue Jan 28 08:54:37 2003
@@ -1561,10 +1561,14 @@
const char *fieldname,
const char *fieldval)
{
+char *f;
if (strcasecmp(fieldname, "ETag") == 0) {
if (ap_table_get(r->notes, "no-etag") != NULL) {
return 1;
}
+}
+if ((f = strchr(fieldval, '\r')) != NULL || (f = strchr(fieldval, '\n')) != NULL)
+{
+ *f = '\0';
}
return (0 < ap_rvputs(r, fieldname, ": ", fieldval, CRLF, NULL));
}
Of course, a check for continuation like in your patch is needed.
Attached is a module to test it with
#include "httpd.h"
#include "http_config.h"
#include "http_core.h"
module MODULE_VAR_EXPORT break_module;
static int break_header(request_rec *r) {
ap_table_set(r->headers_out, "Breaking-Header", "Malicious code\r\n\r\nBad
boy!");
return OK;
}
module MODULE_VAR_EXPORT break_module = {
STANDARD_MODULE_STUFF,
NULL, /* initializer */
NULL, /* dir config creater */
NULL, /* dir merger --- default is to override */
NULL, /* server config */
NULL, /* merge server configs */
NULL, /* command table */
NULL, /* handlers */
NULL, /* filename translation */
NULL, /* check_user_id */
NULL, /* check auth */
NULL, /* check access */
NULL, /* type_checker */
break_header, /* fixups */
NULL, /* logger */
NULL, /* header parser */
NULL, /* child_init */
NULL, /* child_exit */
NULL/* post read-request */
};
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mitigating XSS in the mod_perl API
On Tue, Jan 28, 2003 at 02:50:54PM +, Matt Sergeant wrote:
> For geoff...
>
> On Tue, 28 Jan 2003, Matt Sergeant wrote:
>
> > Index: src/main/http_protocol.c
> > ===
> > RCS file: /home/cvs/apache-1.3/src/main/http_protocol.c,v
> > retrieving revision 1.329
> > diff -u -r1.329 http_protocol.c
> > --- src/main/http_protocol.c3 Oct 2002 20:51:53 - 1.329
> > +++ src/main/http_protocol.c28 Jan 2003 11:26:37 -
> > @@ -1561,8 +1561,16 @@
> > const char *fieldname,
> > const char *fieldval)
> > {
> > +char *line_feed;
> > if (strcasecmp(fieldname, "ETag") == 0) {
> > if (ap_table_get(r->notes, "no-etag") != NULL) {
> > +return 1;
> > +}
> > +}
> > +if ((line_feed = strchr(fieldval, '\n')) != NULL) {
>
> If we find a line feed anywhere, the the line_feed variable points to the
> line feed character.
>
> Now headers in RFC terms can have continuations, which means something
> like:
>
> Refresh: 1;
> url=/foo
>
> So basically a continuation is CRLF WS+ ...
>
> So all we have to do is look for whitespace (space or horizontal tab)
> after the line feed. And that's at line_feed[1]. Anything else is invalid.
thanks for the explanation, I was wondering about it too.
> > +/* don't allow any headers with line feeds in them */
> > +if (line_feed[1] != ' ' && line_feed[1] != '\t') {
> > +/* unless it's a continuation */
> > return 1;
> > }
> > }
Would you consider what I was trying to do in my patch? To just not
discard the header line but rather just terminate when you discover
\n or \r (and not a continuation following).
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mp2 Patch] Apache::Directive->lookup($directive, [$args]);
BTW, the Apache::Directive->as_hash method is nice, but I guess that it's not very useful, since the original order of things is lost, which will break things if you try to feed them back or just trying to view them. If we could use the functionality of Tie::IxHash where the keys sorting is preserved that would be really useful then. Would do you think. __ 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mp2 Patch] Apache::Directive->lookup($directive, [$args]);
Made a few minor style changes to the original patches. Thanks for the
extra eyeballing Stas ;-)
--- /dev/null 2002-08-31 07:31:37.0 +0800
+++ docs/api/Apache/Directive.pod 2003-01-29 10:59:37.0 +0800
@@ -0,0 +1,133 @@
+=head1 NAME
+
+Apache::Directive -- A Perl API for manipulating Apache configuration tree
+
+=head1 SYNOPSIS
+
+ use Apache::Directive;
+
+ my $tree = Apache::Directive->conftree;
+
+ my $documentroot = $tree->lookup('DocumentRoot');
+
+ my $vhost = $tree->lookup('VirtualHost', 'localhost:8000');
+ my $servername = $vhost->{'ServerName'};
+
+ print $tree->as_string;
+
+ use Data::Dumper;
+ print Dumper($tree->as_hash);
+
+ my $node = $tree;
+ while ($node) {
+
+ #do something with $node
+
+ if (my $kid = $node->first_child) {
+ $node = $kid;
+ }
+ elsif (my $next = $node->next) {
+ $node = $next;
+ }
+ else {
+ if (my $parent = $node->parent) {
+ $node = $parent->next;
+ }
+ else {
+ $node = undef;
+ }
+ }
+ }
+
+=head1 DESCRIPTION
+
+C allows its users to search and navigate the internal Apache
+configuration.
+
+Internally, this information is stored in a tree structure. Each node in
+the tree has a reference to it's parent (if it's not the root), its first
+child (if any), and to its next sibling.
+
+=head1 API
+
+Function arguments (if any) and return values are shown in the
+function's synopsis.
+
+=head2 conftree()
+
+ $tree = Apache::Directive->conftree();
+
+Returns the root of the configuration tree.
+
+=head2 next()
+
+ $node = $node->next;
+
+Returns the next sibbling of C<$node>, undef otherwise
+
+=head2 first_child()
+
+ $subtree = $node->first_child;
+
+Returns the first child node of C<$node>, undef otherwise
+
+=head2 parent()
+
+ $parent = $node->parent;
+
+Returns the parent of C<$node>, undef if this node is the root node
+
+=head2 directive()
+
+ $name = $node->directive;
+
+Returns the name of the directive in C<$node>
+
+=head2 args()
+
+ $args = $node->args;
+
+Returns the arguments to this C<$node>
+
+=head2 filename()
+
+ $fname = $node->filename;
+
+Returns the filename this C<$node> was created from
+
+=head2 line_number()
+
+ $lineno = $node->line_number;
+
+Returns the line number in C this C<$node> was created from
+
+=head2 as_string()
+
+ print $tree->as_string();
+
+Returns a string representation of the configuration tree, in httpd.conf format.
+
+=head2 as_hash()
+
+ $config = $tree->as_hash();
+
+Returns a hash representation of the configuration tree, in a format suitable
+for inclusion in EPerlE sections
+
+=head2 lookup($directive, [$args])
+
+Returns node(s) matching a certain value. In list context, it will return all
+matching nodes.
+In scalar context, it will return only the first matching node.
+
+If called with only one C<$directive> value, this will return all nodes from that
+directive:
+
+ @Alias = $tree->lookup('Alias');
+
+Would return all nodes for Alias directives.
+
+If called with an extra C<$args> argument, this will return only nodes where both the
+directive
+and the args matched:
+
+ $VHost = $tree->lookup('VirtualHosts', '_default_:8000');
+
+=cut
Index: t/response/TestApache/conftree.pm
===
RCS file: /home/cvspublic/modperl-2.0/t/response/TestApache/conftree.pm,v
retrieving revision 1.4
diff -u -I'$Id' -I'$Revision' -r1.4 conftree.pm
--- t/response/TestApache/conftree.pm 19 May 2002 01:12:24 - 1.4
+++ t/response/TestApache/conftree.pm 29 Jan 2003 03:07:50 -
@@ -4,6 +4,7 @@
use warnings FATAL => 'all';
use Apache::Test;
+use Apache::TestUtil;
use Apache::TestConfig ();
use Apache::Directive ();
@@ -14,7 +15,7 @@
my $r = shift;
my $cfg = Apache::Test::config();
-plan $r, tests => 7;
+plan $r, tests => 8;
ok $cfg;
@@ -26,43 +27,35 @@
ok $tree;
-my $port = find_config_val($tree, 'Listen');
+my $port = $tree->lookup('Listen');
-ok $port;
+ok t_cmp($vars->{port}, $port);
-ok $port == $vars->{port};
+my $documentroot = $tree->lookup('DocumentRoot');
-my $documentroot = find_config_val($tree, 'DocumentRoot');
+ok t_cmp('HASH' , ref($tree->as_hash()), 'as_hash');
-ok $documentroot;
+ok t_cmp(qq("$vars->{documentroot}"), $documentroot);
-ok $documentroot eq qq("$vars->{documentroot}");
+ok t_cmp(qq("$vars->{documentroot}"), $tree->lookup("DocumentRoot"));
-Apache::OK;
-}
-
-sub find_config_val {
-my($tree, $directive) = @_;
-
-while ($tree) {
-if ($directive eq $tree->directive) {
-return $tree->args;
+#XXX: This test isn't so good, but it's quite problematic to try and _really_
+compare $cfg and $tree...
+{
+ my %vhosts = map { $cfg->{vhosts}{$_}{'name'} => { %{$cfg->{vhosts}{$_}},
+index => $_}} keys %{$cfg->{vhosts}};
+ f
Re: [mp2 Patch] Apache::Directive->lookup($directive, [$args]);
Philippe M. Chiasson wrote: Made a few minor style changes to the original patches. Thanks for the extra eyeballing Stas ;-) I've committed the doc after massaging it. Still can't decide what the best look-n-feel for the API docs to choose, but we are getting there. Regarding the xs and the test, you still had quite a few indentation problems, plus too wide lines (keep under 74 or so), but I've fixed those and committed. Finally you've forgotten the table file, but I've grabbed the one from your previous post, so it's ok. ;) Good work, gozer! Now figure out how to get the hash preserve the keys order ;) May be it's better to s/as_hash/as_list/, it's easy to coerce a list into a hash. __ 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mp2 Patch] Apache::Directive->lookup($directive, [$args]);
On Wed, 2003-01-29 at 11:57, Stas Bekman wrote: > Philippe M. Chiasson wrote: > > Made a few minor style changes to the original patches. Thanks for the > > extra eyeballing Stas ;-) > > I've committed the doc after massaging it. Still can't decide what the best > look-n-feel for the API docs to choose, but we are getting there. Better to have something than nuthin ;-p > Regarding the xs and the test, you still had quite a few indentation problems, > plus too wide lines (keep under 74 or so), but I've fixed those and committed. Hargh ! I am still trying to figure out a way to automatically indent my stuff, but I am failing miserably... Can't get indent to produce mod_perl perfect code... > Finally you've forgotten the table file, but I've grabbed the one from your > previous post, so it's ok. ;) Thanks, and sorry abot that. > Good work, gozer! Now figure out how to get the hash preserve the keys order > ;) I'd put that as a TODO item and in the meantime I'll look if I can just plug Tie::IxHash in there instead of a regular hash. > May be it's better to s/as_hash/as_list/, it's easy to coerce a list into a > hash. Hmm... Not sure it would be any better. Really, as_hash is used internally when looking up containers, like sections. It's after having written it that I realized it could be exposed on the Perl side. Figuring out a way to return a Tie::IxHash ref would certainly be the best solution IMHO. > __ > 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 > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > signature.asc Description: This is a digitally signed message part
Re: [mp2 Patch] Apache::Directive->lookup($directive, [$args]);
Regarding the xs and the test, you still had quite a few indentation problems, plus too wide lines (keep under 74 or so), but I've fixed those and committed. Hargh ! I am still trying to figure out a way to automatically indent my stuff, but I am failing miserably... Can't get indent to produce mod_perl perfect code... Well, I use cperl-mode in xemacs with a few tweaks it works great for me. Good work, gozer! Now figure out how to get the hash preserve the keys order ;) I'd put that as a TODO item and in the meantime I'll look if I can just plug Tie::IxHash in there instead of a regular hash. I remember Doug was against creating any dependancies on the external modules. May be it's better to s/as_hash/as_list/, it's easy to coerce a list into a hash. Hmm... Not sure it would be any better. Really, as_hash is used internally when looking up containers, like sections. It's after having written it that I realized it could be exposed on the Perl side. Sure, but we can have both representations. Or, you can use APR::Table records as values, which if i remember correctly preserve the order. Though I don't think this will work with nesting, unless some magic is applied, because the keys have to be strings. Figuring out a way to return a Tie::IxHash ref would certainly be the best solution IMHO. it certainly can be an optional thing, or at least something for now and fixed later to have a native solution. __ 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-DMODPERL, -DMOD_PERL, -DMOD_PERL2, -DMODPERL2 conundrum
In 1.0 mod_perl extensions were passed -DMOD_PERL by Apache::src, so shouldn't we pass -DMOD_PERL2 from ModPerl::MM and not -DMOD_PERL? At the same time we use and not MOD_PERL2, so it gets all confusing. Can we decide on consistently using the underscore or none in both cases? I know that it's boring when the life is too easy... but My proposal: In order to stay consistent with 1.0 stuff, we go with the underscore, though add '2', so we use -DMOD_PERL2 from ModPerl::MM, for extensions to use. Since is new, we change it to without breaking anything. So it's always -DMOD_PERL2, be it httpd.conf or C code. __ 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: -DMODPERL, -DMOD_PERL, -DMOD_PERL2, -DMODPERL2 conundrum
On Wed, 2003-01-29 at 14:57, Stas Bekman wrote: > In 1.0 mod_perl extensions were passed -DMOD_PERL by Apache::src, so shouldn't > we pass -DMOD_PERL2 from ModPerl::MM and not -DMOD_PERL? > > At the same time we use and not MOD_PERL2, so it gets all > confusing. Can we decide on consistently using the underscore or none in both > cases? I know that it's boring when the life is too easy... but > > My proposal: > > In order to stay consistent with 1.0 stuff, we go with the underscore, though > add '2', so we use -DMOD_PERL2 from ModPerl::MM, for extensions to use. > > Since is new, we change it to without > breaking anything. > > So it's always -DMOD_PERL2, be it httpd.conf or C code. +1 for MOD_PERL2 consistently everywhere > __ > 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 > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > signature.asc Description: This is a digitally signed message part
