Re: Cookie authentication

2001-11-19 Thread Jim Smith

On Fri, Nov 16, 2001 at 02:09:25AM +0100, Tom Bille wrote:
 The aim of the cookie example in the eagle book is a bit more than just 
authentication. Most of the answers here to use a 
 session ID here are quite right for most purposes, but the code in the eagle book 
offers to store information on the client side 
 with the security of a signature. Its NOT just authentication.
 This has some advantages for applications which are on more than one server, which 
have to use an expensive central DB 
 lookup and/or are not connected at all, since the only thing to share is the secret.
[snip]

And for the academically inclined, Authen::Ticket (which I need to go back
and update) is based on the Eagle book's example but different :/  It uses
a PKI-like solution for ensuring authenticity of the cookies (at least
someone can't just make up a cookie out of thin air).  If you're using
FreeBSD, I believe there's even a port for it (much to my surprise).

--jim



Re: Fastcgi on win [Was: Re: Documentation patch for mod_perl?]

2001-11-19 Thread Perrin Harkins

 So mod_perl has a slight speed edge over fastcgi (which is overthrottled a
 little with four servers).

Really?  Maybe this is because multi-process handling isn't as fast on NT.
Does it change much if you vary the number of servers?

My goal is to give some kind of useful suggestion to people who need better
performance on NT than mod_perl can currently give.

- Perrin




Re: Fastcgi on win [Was: Re: Documentation patch for mod_perl?]

2001-11-19 Thread Alessandro Forghieri

Greetings.

 So mod_perl has a slight speed edge over fastcgi (which is overthrottled
a
 little with four servers).

Really? Maybe this is because multi-process handling isn't as fast on NT.
Does it change much if you vary the number of servers?

Well, I am getting a little wary of the numbers I get with ab, and on the
significance of the
-c[oncurrency]  switch. In fact, by using different logins on the same
client machine (rather than blasting the server from a single login), I get
consistently lower request per second numbers than I previously posted (in
the 7 rps for mod_perl, 5rps  for fastcgi). Besides, as  I am testing a
single CPU load machine against a single CPU  server machine, I am sort of
measuring the ratio of the respective process/thread/whatever switching
efficiency, whereas I would really need separate (or multiple CPU) clients.
The gist of all this is that changing numbers of servers does not seem to
matter much, but that happens at a juncture where nothing else does. For
what it's worth though, mod_perl tends to be consistently a little faster.

My goal is to give some kind of useful suggestion to people who need better
performance on NT than mod_perl can currently give.

That probably requires a definition of performance - not easy. If the goal
is responsiveness, and response times are very variable, then anything
(including CGI) would be more performant, given that a stuck mod_perl
freezes the entire server. Other application domains, however, will probably
warrant different metrics. From the vantage point where I am standing now,
fastCGI does not look bad (but I really have to test it much more than
this). For people that do not like the constraints of
Apache::Registry, this solution may not be ideal at all, though...

Cheers,
alf




[ANNOUNCE] AI::Menu 0.01

2001-11-19 Thread James G Smith

The uploaded file

AI-Menu-0.01.tar.gz

has entered CPAN as

  file: $CPAN/authors/id/J/JS/JSMITH/AI-Menu-0.01.tar.gz
  size: 5587 bytes
   md5: 8272d6782f0cb041e27ffd50cd38ce56

readme: http://sourceforge.net/project/shownotes.php?release_id=62025
download: http://prdownloads.sourceforge.net/perlkb/AI-Menu-0.01.tar.gz

This is part of the PerlKB project:

  http://sourceforge.net/projects/perlkb/

This is an attempt to take a graph representing arbitrary relationships
between categories and functions and turn it into a tree that can
be used as a menu.

This should be considered experimental at this point.  See the
readme for a list of known issues.
+--
James Smith - [EMAIL PROTECTED] | http://www.jamesmith.com/
  [EMAIL PROTECTED]  | http://cis.tamu.edu/systems/opensystems/
+--



[OT] [But fun] Cookies and Microsoft

2001-11-19 Thread Nick Tonkin


Speaking of the risks of using cookies for auth* stuff:

http://dailynews.yahoo.com/h/cn/2009/tc/microsoft_apologizes_in_security_flap_1.html



~~~
Nick Tonkin




Test.. Do ignore..

2001-11-19 Thread Ali Pakkan


This is a test message..




Re: Doing Authorization using mod_perl from a programmers perspective

2001-11-19 Thread Randal L. Schwartz

 fliptop == fliptop  [EMAIL PROTECTED] writes:

fliptop i have found that using the HTTP_USER_AGENT environment
fliptop variable instead of ip address solves the problem with proxy
fliptop servers and the md5 hash.  anyone ever tried this as a simple
fliptop workaround?

Nobody with any sense.  It's flawed.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!



Re: Doing Authorization using mod_perl from a programmers perspective

2001-11-19 Thread Jon Robison

Randall, you want to expound upon that?

--Jon Robison

Randal L. Schwartz wrote:
 
  fliptop == fliptop  [EMAIL PROTECTED] writes:
 
 fliptop i have found that using the HTTP_USER_AGENT environment
 fliptop variable instead of ip address solves the problem with proxy
 fliptop servers and the md5 hash.  anyone ever tried this as a simple
 fliptop workaround?
 
 Nobody with any sense.  It's flawed.
 
 --
 Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
 Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
 See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!



Re: Doing Authorization using mod_perl from a programmers perspective

2001-11-19 Thread Jon Robison

How about using an Apache::Sessions id instead of IP address?

--Jon Robison

Randal L. Schwartz wrote:
 
  fliptop == fliptop  [EMAIL PROTECTED] writes:
 
 fliptop i have found that using the HTTP_USER_AGENT environment
 fliptop variable instead of ip address solves the problem with proxy
 fliptop servers and the md5 hash.  anyone ever tried this as a simple
 fliptop workaround?
 
 Nobody with any sense.  It's flawed.
 
 --
 Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
 Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
 See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!



Re: Doing Authorization using mod_perl from a programmers perspective

2001-11-19 Thread Randal L. Schwartz

 Jon == Jon Robison [EMAIL PROTECTED] writes:

Jon Randall, you want to expound upon that?

Barely ignoring the spelling of my name, I'll simply claim

it's not unique.

Neither is IP address.  Or anything that you haven't specifically
round-tripped to the browser.  And that doesn't stop someone from
making another browser respond in the same way, or that browser
respond in a different way.

But this is obvious.  I'm confused about why I'd have to explain it. :(

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!



Re: Doing Authorization using mod_perl from a programmers perspective

2001-11-19 Thread DeWitt Clinton

On Mon, Nov 19, 2001 at 07:51:55AM -0800, Randal L. Schwartz wrote:

 But this is obvious.  I'm confused about why I'd have to explain it. :(

I posted this a year or two back:

[EMAIL PROTECTED]">http://mathforum.org/epigone/modperl/jytwortwor/[EMAIL PROTECTED]


Here is the relevant part of that post:


It makes sense to start with the requirements for what it means to 
implement those secure features.  My requirements have an obvious 
e-commerce bias, and should probably be heavily reviewed by anyone 
thinking of using this design for online banking or government work. 

First, I'd like to introduce the notion of a secure session.  Secure
sessions have some subtle differences from the traditional notion of
the session, and I'll point those out when they appear.

The secure session has the following properties:

*) The user is able to initiate a secure session by providing proper
credentials (i.e., a username and password pair) via a login process.

*) The user is able to terminate the secure session via a logout
process.

*) Secure sessions must be able to time out automatically.

*) Secure sessions must *never* transmit sensitive data (such as the
password) over insecure channels.

*) The secure session, while it requires the use of a secure protocol
(such as HTTPS), should not require the use of cookies.  Cookies,
however, can be employed to extend the functionality of the system.  

Additionally, I feel that one of the essential requirements to any
enterprise quality, highly scalable, and fault-tolerant system is the
ability to store session state on a tier other than the front-end.
This usually means storing state in a shared database, but there are
other options.

A very effective method of meeting the requirements above is to use a
two token architecture.  The first token is a user identifier, which
can be passed over insecure channels.  This user identification token
can be used to restore state that isn't particularly sensitive, such
as a shopping cart or user preferences.  The second token is a secure
identifier, which is never passed over insecure channels.  The secure
identifier is required to access sensitive data, such as credit card
data. (It is possible to create an architecture that uses *only* the
secure token, but there are significant benefits in terms of
flexibility afforded by using two tokens, so I won't go into the one
token model here.)

The fundamental goal of the secure token is to a) keep it safe from
prying eyes, and b) use it is a requirement for accessing secure data.

Tokens can be passed in one of two ways.  First, the token can be
passed as part of the URL.  Second, the token can be passed in a
cookie.  I've found it very useful to create an initialization
procedure inside applications that check both places for these tokens,
and abstract the particular mechanism used to pass them.  Note,
however, that is important to remember how the token was passed -- if
it came from a cookie, it is cosmetic to not pass it around in the
URL.  I also recommend creating a library used in your templates that
has a function to build URLs that automatically append the tokens if
necessary.  Since it is critical that secure tokens are never passed
in the clear, it really helps to have that function, because it can
prevent the secure token from being sent via an insecure page in a URL
(i.e., only setting secure tokens in URLs that contain https).

The user identification token is typically used to restore state from
the database.  It is created whenever a page is viewed and the client 
has either not provided one (via the URL or a cookie), or the token
they provide doesn't exist in the database.  This token should then be 
set in both the URL and in a cookie.  On the subsequent page request,
if the user identification token is found in a cookie, it is probably
safe to stop putting it in the URL.  However, if the token is found
only in the URL (probably meaning the client does not use cookies) the 
server should not try writing the cookie again.  

The advantage of the cookie is such that the user can insecurely
identify themselves across browser sessions.  This is perfectly
acceptable when used to restore some insensitive state data (such as a
name or shopping cart).  However, the system still functions without
the cookie.  The user can now login to associate their client with
particular stored user information.

The login process is as follows:

1) The client connects to a secure page that presents a form
requesting a username and password.  (There has been much discussion
about whether a HTTP form that POSTS to a secure page will encrypt the 
posted data.  There is too much ambiguity here -- I recommend using
HTTPS on the login form as well.)  The ACTION of the form must also
be a secure page.

2) On receiving the username and password, the server compares an
encrypted version of the password with the stored encrypted password
associated with that customer.  If the passwords do not match, 

Re: Doing Authorization using mod_perl from a programmers perspective

2001-11-19 Thread J. J. Horner


* Randal L. Schwartz ([EMAIL PROTECTED]) [09 11:00]:
  Jon == Jon Robison [EMAIL PROTECTED] writes:
 
 Jon Randall, you want to expound upon that?
 
 Barely ignoring the spelling of my name, I'll simply claim
 
 it's not unique.
 
 Neither is IP address.  Or anything that you haven't specifically
 round-tripped to the browser.  And that doesn't stop someone from
 making another browser respond in the same way, or that browser
 respond in a different way.
 
 But this is obvious.  I'm confused about why I'd have to explain it. :(
 


I think Randal has pointed out many times, as have others, that a browser isn't
a person.  One doesn't want to authenticate browsers, one wants to authenticate
people.  Using browser specific information to authenticate a person
is not only impossible to do successfully, it is silly to try.  Using cookies is 
only a little bit less unsuccessful.

Also, please be sure to note the gotcha in the mod_perl guide that gives you 
warning that all browsers behave differently when dealing with a 401 status
code.  Be sure to take that into account.

Thanks,
JJ

-- 
J. J. Horner
H*,6a686f726e657240326a6e6574776f726b732e636f6d
***
H*,6a6a686f726e65724062656c6c736f7574682e6e6574

Freedom is an all-or-nothing proposition:  either we 
are completely free, or we are subjects of a
tyrannical system.  If we lose one freedom in a
thousand, we become completely subjugated.



msg22686/pgp0.pgp
Description: PGP signature


Linux Hello World Benchmarks - 11/19/2001

2001-11-19 Thread Joshua Chamas

Hey, [[ NUMBERS ARE BELOW ]]

It has been a while, but here's a new set of Hello World benchmarks!
What took me so long in getting these out is that the java web environments
that I had set up would keep crashing during the tests in ways that would
not only render their benchmarks meaningless, but also skewed the results
for other tests, say when a java thread would spin out of control!

You can download the latest benchmark suite to run on your system at:

  http://www.chamas.com/bench/hello.tar.gz

It seems to run on linux  solaris just fine, though the tests that
are run depend on what environments you have set up.  Please see the
distribution README on how to run the suite for yourself.

--Josh


METHODOLOGY: These latest numbers come from my running the pubbench.sh script:

  ]# cat pubbench.sh 
  #!/bin/bash

  ./bench.pl -version --ram --init-exec=perl javainit.pl -restart -time=180 
--store=results
  perl ./javainit.pl -stop

The javainit.pl will kill any of my existing java environments, and if the current
test needs java will start them up.  The test run for 180 seconds total in 60 second 
batches, and for each 60 second run the javainit.pl script will be executed.  

The --ram flag attempts to calculate the RAM used by each test on my linux system 
during each 60 second test with the results averaged across each, so for applications 
with memory leaks, the RAM used only shows 60 seconds worth of them.  The RAM
calculation looks at RAM used  SWAP used from the linux /proc/meminfo file... as
it looks at RAM before the httpd is fired up, but after the init-exec script
executes, the RAM does not take into account the java web server environments 
being started, just memory usage that occurs after they start being used.

DISCLAIMER: These numbers are just that, numbers.  Please don't let them
upset you.  If you have a positive contribution that you would like to make, 
you may download the source code and submit patches ( preferably as diff -u )
to the test suite.  This benchmark suite has evolved over years of benchmarking, 
and takes the point of view that web environments can only be well compared when 
run on the exact same system configuration... this is why the suite is done 
is such a way that you can run it on _your_ system giving you results relevant
to you!

NUMBERS: And without further adieu ... ( see NOTES below )

Test Name   Test File Hits/sec  # of Hits Time(sec) secs/Hit  
Bytes/Hit Mem(KB)   
-   - - - - - 
- - 
Apache::ASP v2.29 2000  h2000.asp  216.8 39042180.090.004613  
28998 33632 
Apache::Registry v2.01 2000 mod_per h2000.reg  341.3 61442180.040.002930  
28179 16081 
HTML::Embperl v1.3.0 2000   h2000.epl  113.2 20391180.120.008833  
28841 20418 
HTML::Mason v1.03 2000  h2000.mas   84.0 15115180.030.011911  
28799 112220
HTML::Template v2.4 2000h2000.htm   99.1 17848180.030.010087  
29152 50292 
mod_caucho JSP 2000 h2000.jsp   97.6 17617180.540.010248  
28965 14057 
mod_jserv JSP 2000  h2000.jsp  148.7 26773180.040.006725  
29408 29613 
mod_php PHP 2000h2000.php  258.2 46477180.020.003873  
28866 10212 
Template v2.04 Toolkit 2000 h2000.tt53.3  9604180.030.018745  
28889 55629 

Test Name   Test File Hits/sec  # of Hits Time(sec) secs/Hit  
Bytes/Hit Mem(KB)   
-   - - - - - 
- - 
Apache::ASP v2.29   hello.asp  349.8 62985180.050.002859  
242   29601 
Apache::Dispatch v0.09 handler  hello/wor  585.8105443180.010.001707  
197   9205  
Apache::ePerl   hello.epe  347.1 62508180.080.002881  
218   17477 
Apache::Registry v2.01 CGI Raw  hello.cgi  677.7122003180.030.001476  
5213061 
Apache::Registry v2.01 CGI.pm   hello.cgi  449.7 80967180.050.002224  
217   20717 
Apache::SSI v2.16   hello.sht  546.7 98426180.030.001829  
200   13061 
CGI::SpeedyCGI CGI Raw  hello.scg  159.6 28722180.000.006267  
197   9748  
CGI::SpeedyCGI CGI.pm   hello.scg  145.1 26117180.010.006892  
217   10648 
HTML static hello.htm  879.215170.610.001137  
312   1982  
HTML::Embperl v1.3.0hello.epl  463.6 83471180.050.002157  
221   17333 
HTML::Mason v1.03   hello.mas  368.5 66348180.040.002714  
198   29009 
HTML::Template v2.4   

Re: Linux Hello World Benchmarks - 11/19/2001

2001-11-19 Thread Perrin Harkins

on 11/19/01 8:05 PM, Joshua Chamas at [EMAIL PROTECTED] wrote:
 It has been a while, but here's a new set of Hello World benchmarks!

There was a recent announcement of HTML::Template::JIT, and Template Toolkit
has an XS option now.  Any chance you could put those into the next round?
- Perrin




Re: Linux Hello World Benchmarks - 11/19/2001

2001-11-19 Thread Joshua Chamas

Perrin Harkins wrote:
 
 on 11/19/01 8:05 PM, Joshua Chamas at [EMAIL PROTECTED] wrote:
  It has been a while, but here's a new set of Hello World benchmarks!
 
 There was a recent announcement of HTML::Template::JIT, and Template Toolkit
 has an XS option now.  Any chance you could put those into the next round?
 - Perrin

OK, I upgraded Template Toolkit to version 2.06 with XS option on 
for all templates, and performance is much improved!!  

However, HTML::Template::JIT will likely not work on my system any 
time soon, because it was written for perl 5.6, and I only run 5.00503 
currently. Someone else can submit a test  config specifically for 
HTML::Template::JIT, I'd suggest the h2000 type where speed matters, and 
I'll add it to the test suite even it I can't run the benchmark myself.

[hello]# ./bench.pl -type=2000 -ram -time=60

Test Name   Test File Hits/sec  # of Hits Time(sec) secs/Hit  
Bytes/Hit Mem(KB)   
-   - - - - - 
- - 
Apache::ASP 2000h2000.asp  209.4 12566 60.020.004776  
28998 33200 
Apache::Registry 2000 mod_perl API  h2000.reg  327.0 19622 60.020.003059  
28179 15300 
HTML::Embperl 2000  h2000.epl  107.5  6465 60.120.009299  
28841 20048 
HTML::Mason 2000h2000.mas   80.8  4849 60.000.012374  
28799 110292
HTML::Template 2000 h2000.htm   95.4  5724 60.010.010484  
29152 49932 
mod_php PHP 2000h2000.php  247.6 14862 60.020.004038  
28866 10384 
Template Toolkit 2000   h2000.tt   125.5  7533 60.020.007967  
28889 55748 

-- Josh
_
Joshua Chamas   Chamas Enterprises Inc.
NodeWorks Founder   Huntington Beach, CA  USA 
http://www.nodeworks.com1-714-625-4051



cvs commit: modperl-2.0/xs/Apache/Connection - New directory

2001-11-19 Thread dougm

dougm   01/11/19 09:32:03

  modperl-2.0/xs/Apache/Connection - New directory



cvs commit: modperl-2.0/xs/Apache/Connection Apache__Connection.h

2001-11-19 Thread dougm

dougm   01/11/19 09:32:46

  Added:   xs/Apache/Connection Apache__Connection.h
  Log:
  the new client_socket code
  
  Revision  ChangesPath
  1.1  modperl-2.0/xs/Apache/Connection/Apache__Connection.h
  
  Index: Apache__Connection.h
  ===
  static MP_INLINE
  apr_socket_t *mpxs_Apache__Connection_client_socket(pTHX_ conn_rec *c,
  apr_socket_t *s)
  {
  apr_socket_t *socket =
  ap_get_module_config(c-conn_config, core_module);
  
  if (s) {
  ap_set_module_config(c-conn_config, core_module, s);
  }
  
  return socket;
  }
  
  
  



cvs commit: modperl-2.0/t/directive setupenv.t

2001-11-19 Thread dougm

dougm   01/11/19 10:23:20

  Modified:t/directive setupenv.t
  Log:
  remove debug prints (-d lwp gives plenty)
  
  Revision  ChangesPath
  1.2   +1 -3  modperl-2.0/t/directive/setupenv.t
  
  Index: setupenv.t
  ===
  RCS file: /home/cvs/modperl-2.0/t/directive/setupenv.t,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- setupenv.t2001/11/19 00:14:53 1.1
  +++ setupenv.t2001/11/19 18:23:20 1.2
  @@ -12,7 +12,7 @@
   my $env = GET_BODY $location;
   
   ok $env;
  -print $env;
  +
   my %env;
   
   for my $line (split /\n/, $env) {
  @@ -20,8 +20,6 @@
   my($key, $val) = split /=/, $line, 2;
   $env{$key} = $val || '';
   }
  -use Data::Dumper;
  -print Dumper \%env;
   
   ok t_cmp $location, $env{REQUEST_URI}, testing REQUEST_URI;
   
  
  
  



cvs commit: modperl-2.0/src/modules/perl modperl_util.c

2001-11-19 Thread dougm

dougm   01/11/19 15:24:46

  Modified:src/modules/perl modperl_util.c
  Log:
  give modperl_sv2pool more to choose from
  
  Revision  ChangesPath
  1.31  +28 -10modperl-2.0/src/modules/perl/modperl_util.c
  
  Index: modperl_util.c
  ===
  RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_util.c,v
  retrieving revision 1.30
  retrieving revision 1.31
  diff -u -r1.30 -r1.31
  --- modperl_util.c2001/11/06 18:39:41 1.30
  +++ modperl_util.c2001/11/19 23:24:46 1.31
  @@ -170,15 +170,21 @@
   
   apr_pool_t *modperl_sv2pool(pTHX_ SV *obj)
   {
  -char *classname;
  +apr_pool_t *p = NULL;
  +char *classname = NULL;
  +IV ptr = 0;
   
  -if (!(SvROK(obj)  (SvTYPE(SvRV(obj)) == SVt_PVMG))) {
  -return NULL;
  +if ((SvROK(obj)  (SvTYPE(SvRV(obj)) == SVt_PVMG))) {
  +ptr = SvObjIV(obj);
  +classname = SvCLASS(obj);
   }
  -
  -classname = SvCLASS(obj);
  +else {
  +STRLEN len;
  +classname = SvPV(obj, len);
  +}
   
   if (*classname != 'A') {
  +/* XXX: could be a subclass */
   return NULL;
   }
   
  @@ -187,25 +193,37 @@
   switch (*classname) {
 case 'P':
   if (strEQ(classname, Pool)) {
  -return (apr_pool_t *)SvObjIV(obj);
  +p = (apr_pool_t *)ptr;
   }
  +break;
 default:
  -return NULL;
  +break;
   };
   }
   else if (strnEQ(classname, Apache::, 8)) {
   classname += 8;
   switch (*classname) {
  +  case 'C':
  +if (strEQ(classname, Connection)) {
  +p = ptr ? ((conn_rec *)ptr)-pool : NULL;
  +}
  +break;
 case 'R':
   if (strEQ(classname, RequestRec)) {
  -return ((request_rec *)SvObjIV(obj))-pool;
  +p = ptr ? ((request_rec *)ptr)-pool : NULL;
  +}
  +break;
  +  case 'S':
  +if (strEQ(classname, Server)) {
  +p = ptr ? ((server_rec *)ptr)-process-pconf : NULL;
   }
  +break;
 default:
  -return NULL;
  +break;
   };
   }
   
  -return NULL;
  +return p ? p : modperl_global_get_pconf();
   }
   
   char *modperl_apr_strerror(apr_status_t rv)
  
  
  



cvs commit: modperl-2.0/xs/tables/current/ModPerl FunctionTable.pm

2001-11-19 Thread dougm

dougm   01/11/19 15:32:00

  Modified:xs/Apache/ServerUtil Apache__ServerUtil.h
   xs/maps  apache_functions.map
   xs/tables/current/ModPerl FunctionTable.pm
  Log:
  fix Apache::server_root_relative arguments to be the same as apache api
  
  use modperl_sv2pool() to find the apr_pool_t *
  
  Revision  ChangesPath
  1.7   +3 -11 modperl-2.0/xs/Apache/ServerUtil/Apache__ServerUtil.h
  
  Index: Apache__ServerUtil.h
  ===
  RCS file: /home/cvs/modperl-2.0/xs/Apache/ServerUtil/Apache__ServerUtil.h,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- Apache__ServerUtil.h  2001/11/12 22:42:28 1.6
  +++ Apache__ServerUtil.h  2001/11/19 23:32:00 1.7
  @@ -43,18 +43,10 @@
   modperl_global_get_server_rec()
   
   static MP_INLINE char *mpxs_ap_server_root_relative(pTHX_
  -const char *fname,
  -apr_pool_t *p)
  +SV *sv,
  +const char *fname)
   {
  -if (!fname) {
  -fname = ;
  -}
  +apr_pool_t *p = modperl_sv2pool(aTHX_ sv);
   
  -if (!p) {
  -/* XXX: should do something better if called at request time
  - * without a pool
  - */
  -p = modperl_global_get_pconf();
  -}
   return ap_server_root_relative(p, fname);
   }
  
  
  
  1.38  +1 -1  modperl-2.0/xs/maps/apache_functions.map
  
  Index: apache_functions.map
  ===
  RCS file: /home/cvs/modperl-2.0/xs/maps/apache_functions.map,v
  retrieving revision 1.37
  retrieving revision 1.38
  diff -u -r1.37 -r1.38
  --- apache_functions.map  2001/11/12 22:42:28 1.37
  +++ apache_functions.map  2001/11/19 23:32:00 1.38
  @@ -152,7 +152,7 @@
ap_get_server_built
ap_get_server_version
ap_psignature | | r,prefix
  - ap_server_root_relative | mpxs_ | fname=NULL, p=NULL
  + ap_server_root_relative | mpxs_ | SV *:p, fname=
   
   MODULE=Apache::Connection   PACKAGE=guess
ap_get_remote_host
  
  
  
  1.52  +5 -5  modperl-2.0/xs/tables/current/ModPerl/FunctionTable.pm
  
  Index: FunctionTable.pm
  ===
  RCS file: /home/cvs/modperl-2.0/xs/tables/current/ModPerl/FunctionTable.pm,v
  retrieving revision 1.51
  retrieving revision 1.52
  diff -u -r1.51 -r1.52
  --- FunctionTable.pm  2001/11/19 22:40:12 1.51
  +++ FunctionTable.pm  2001/11/19 23:32:00 1.52
  @@ -2,7 +2,7 @@
   
   # !!
   # ! WARNING: generated by ModPerl::ParseSource/0.01
  -# !  Mon Nov 19 14:57:48 2001
  +# !  Mon Nov 19 15:11:46 2001
   # !  do NOT edit, any changes will be lost !
   # !!
   
  @@ -4827,12 +4827,12 @@
   'name' = 'my_perl'
 },
 {
  -'type' = 'const char *',
  -'name' = 'fname'
  +'type' = 'SV *',
  +'name' = 'sv'
 },
 {
  -'type' = 'apr_pool_t *',
  -'name' = 'p'
  +'type' = 'const char *',
  +'name' = 'fname'
 }
   ]
 },
  
  
  



cvs commit: modperl-2.0/lib/Apache compat.pm

2001-11-19 Thread dougm

dougm   01/11/19 15:33:21

  Modified:lib/Apache compat.pm
  Log:
  add support for 1.x style $r-server_root_relative
  
  Revision  ChangesPath
  1.24  +3 -0  modperl-2.0/lib/Apache/compat.pm
  
  Index: compat.pm
  ===
  RCS file: /home/cvs/modperl-2.0/lib/Apache/compat.pm,v
  retrieving revision 1.23
  retrieving revision 1.24
  diff -u -r1.23 -r1.24
  --- compat.pm 2001/11/08 03:19:47 1.23
  +++ compat.pm 2001/11/19 23:33:21 1.24
  @@ -78,6 +78,9 @@
   
   package Apache::RequestRec;
   
  +#to support $r-server_root_relative
  +*server_root_relative = \Apache::server_root_relative;
  +
   #we support Apache-request; this is needed to support $r-request
   #XXX: seems sorta backwards
   *request = \Apache::request;
  
  
  



cvs commit: modperl-2.0/t/response/TestAPI server_util.pm

2001-11-19 Thread dougm

dougm   01/11/19 15:47:24

  Modified:t/response/TestAPI server_util.pm
  Log:
  add tests for Apache::server_root constant
  
  Revision  ChangesPath
  1.4   +10 -2 modperl-2.0/t/response/TestAPI/server_util.pm
  
  Index: server_util.pm
  ===
  RCS file: /home/cvs/modperl-2.0/t/response/TestAPI/server_util.pm,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- server_util.pm2001/11/19 23:32:27 1.3
  +++ server_util.pm2001/11/19 23:47:24 1.4
  @@ -14,7 +14,7 @@
   
   my $s = $r-server;
   
  -plan $r, tests = 7;
  +plan $r, tests = 9;
   
   for my $p ($r-pool, $r-connection-pool,
  $r, $r-connection, $r-server)
  @@ -24,7 +24,15 @@
   ok -d $dir;
   }
   
  -my $dir = Apache-server_root_relative('logs'); #1.x ish
  +my $dir = Apache::server_root; #constant
  +
  +ok -d $dir;
  +
  +$dir = join '/', Apache::server_root, 'logs';
  +
  +ok $dir eq Apache::server_root_relative($r-pool, 'logs');
  +
  +$dir = Apache-server_root_relative('logs'); #1.x ish
   
   ok -d $dir;
   
  
  
  



cvs commit: modperl-2.0/build make_etags

2001-11-19 Thread stas

stas01/11/19 18:56:35

  Modified:buildmake_etags
  Log:
  - enable working from the build dir
  - make the script work for various etags util versions
  
  Revision  ChangesPath
  1.2   +3 -2  modperl-2.0/build/make_etags
  
  Index: make_etags
  ===
  RCS file: /home/cvs/modperl-2.0/build/make_etags,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- make_etags2001/01/02 20:35:46 1.1
  +++ make_etags2001/11/20 02:56:35 1.2
  @@ -13,6 +13,7 @@
   apache_src=$root/httpd-2.0/
   modperl_src=$root/modperl-2.0/src/
   
  +cd $root/modperl-2.0
   rm -f src/modules/perl/etag_files
   
   for dir in $apache_src $modperl_src $perl_src; do
  @@ -20,6 +21,6 @@
   find $dir -follow -name '*.[ch]'  src/modules/perl/etag_files
   done
   
  -(cd src/modules/perl  etags -L etag_files)
  +(cd src/modules/perl  etags `cat etag_files`)
   
  -rm -f src/modules/perl/etag_files
  \ No newline at end of file
  +rm -f src/modules/perl/etag_files