$r->filename, can I do this here ?

2008-10-17 Thread André Warnier

Hi.

In a PerlFixupHandler, I want to use $r->filename to reset the target of 
a PUT request, so as to "trick" the following Apache PUT content handler 
into writing the PUT-ted file somewhere else than what the original URL 
said.


What I am uncertain of, is whether I can (am allowed to ?) actually do 
this in the PerlFixupHandler, considering all the steps Apache goes 
through before to walk the original path etc..

Or if this opens any security or logical issues that I am unaware of etc..

I know that the path I am providing is correct and allowed, this is the 
actual directory and filename where I want this file to land.
And I have done the AAA phases before, based on the original path and 
that is OK also.


Thanks in advance,
André


Re: $r->filename, can I do this here ?

2008-10-17 Thread Torsten Foertsch
On Fri 17 Oct 2008, André Warnier wrote:
> In a PerlFixupHandler, I want to use $r->filename to reset the target
> of a PUT request, so as to "trick" the following Apache PUT content
> handler into writing the PUT-ted file somewhere else than what the
> original URL said.

Yes you are allowed to do that. One thing you may have to consider is 
the $r->finfo object (sort of stat() result). It is created in the core 
maptostorage handler. So, if $r->filename is changed afterwards it is 
out of sync. Don't know if your response handler uses it, probably not.

Torsten

--
Need professional mod_perl support?
Just hire me: [EMAIL PROTECTED]


Re: $r->filename, can I do this here ?

2008-10-17 Thread André Warnier

Sorry, hit the reply button too quickly and didn't send it to the list..

Torsten Foertsch wrote:

On Fri 17 Oct 2008, André Warnier wrote:

In a PerlFixupHandler, I want to use $r->filename to reset the target
of a PUT request, so as to "trick" the following Apache PUT content
handler into writing the PUT-ted file somewhere else than what the
original URL said.


Yes you are allowed to do that. One thing you may have to consider is 
the $r->finfo object (sort of stat() result). It is created in the core 
maptostorage handler. So, if $r->filename is changed afterwards it is 
out of sync. Don't know if your response handler uses it, probably not.



Thanks.
I don't use $r->finfo.
But mod_dav is the content handler, and it may use the underlying Apache
information. Any way I can kind of "force" Apache to update it's
information after I call $r->filename, or does it already do that anyway ?




Re: $r->filename, can I do this here ?

2008-10-17 Thread Torsten Foertsch
On Fri 17 Oct 2008, André Warnier wrote:
> Any way I can kind of "force" Apache to update it's
> information after I call $r->filename, or does it already do that
> anyway ?

See the example in
http://perl.apache.org/docs/2.0/api/Apache2/RequestRec.html#C_filename_

Torsten

--
Need professional mod_perl support?
Just hire me: [EMAIL PROTECTED]


Re: $r->filename, can I do this here ?

2008-10-17 Thread André Warnier

Torsten Foertsch wrote:

On Fri 17 Oct 2008, André Warnier wrote:

Any way I can kind of "force" Apache to update it's
information after I call $r->filename, or does it already do that
anyway ?


See the example in
http://perl.apache.org/docs/2.0/api/Apache2/RequestRec.html#C_filename_


Thanks again.
It is very clear in the doc, I just never thought of looking there..
Sorry.



Custom Error Log for Specific URL/File matches

2008-10-17 Thread eric.berg
I'd like to be able to provide separate logs for developers who are
devloping in their ~/public_html directories so that any error log
messages for requests made for content that is in one of those
directories would be logged to a file in that user's directory instead
of (or in addition to) the standard error log.

I think I've found sample code that brings me close, but I haven't been
able to figure out how to get the text of the error message.  I'd like
to do this for both system-generated errors (i.e., compile errors) as
well as for any STDERR generated by my code.

Thanks.  I appreciate the help as always.

Eric
___

This e-mail may contain information that is confidential, privileged or 
otherwise protected from disclosure. If you are not an intended recipient of 
this e-mail, do not duplicate or redistribute it by any means. Please delete it 
and any attachments and notify the sender that you have received it in error. 
Unless specifically indicated, this e-mail is not an offer to buy or sell or a 
solicitation to buy or sell any securities, investment products or other 
financial product or service, an official confirmation of any transaction, or 
an official statement of Barclays. Any views or opinions presented are solely 
those of the author and do not necessarily represent those of Barclays. This 
e-mail is subject to terms available at the following link: 
www.barcap.com/emaildisclaimer. By messaging with Barclays you consent to the 
foregoing.  Barclays Capital is the investment banking division of Barclays 
Bank PLC, a company registered in England (number 1026167) with its registered 
office at 1 Churchill Place, London, E14 5HP.  This email may relate to or be 
sent from other members of the Barclays Group.
___


Reducing memory usage using fewer cgi programs

2008-10-17 Thread Thomas Hilbig
I have about a dozen small cgi programs under mod_perl2 that all pretty well 
look like this..

 use CGI;
 use DBI;
 use perlchartdir ; # graphing
 fetch parameters
 build SQL and fetch data from database
 build graph image from data
 send image

Under mod_perl, will the memory footprint of the libraries be shared across all 
of the programs that use them, or could I reduce the memory usage by merging 
all of the programs into one larger program (a maintenance problem, but worth 
while if it saves memory)?  

I also use a PerlRequire startup.pl to preload most modules (CGI, DBI), but I 
thought that was only for quicker startup times and not for sharing memory.  Is 
that correct?


Thanks, Tom



__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


Re: Reducing memory usage using fewer cgi programs

2008-10-17 Thread Michael Peters

Thomas Hilbig wrote:

I have about a dozen small cgi programs under mod_perl2 that all pretty well 
look like this..

 use CGI;
 use DBI;
 use perlchartdir ; # graphing


To think about how this works under mod_perl, pretend that all of your scripts are put together into 
1 larger script and all those "use" statements are repeated. Does having multiple "use CGI" 
statements make your script use more memory? No. CGI.pm is only loaded once.



Under mod_perl, will the memory footprint of the libraries be shared across all 
of the programs that use them


The specifics depend on what OS you're running, what version of Apache/mod_perl you're running, but 
it's basically like this: Each Apache child has it's own Perl interpreter and what is loaded in that 
interpreter is persistant across requests. So different scripts can use the same CGI.pm or DBI that 
you've loaded for another script. Combining them all into the same program won't make any noticeable 
difference in memory one way or the other.



I also use a PerlRequire startup.pl to preload most modules (CGI, DBI), but I 
thought that was only for quicker startup times and not for sharing memory.  Is 
that correct?


Preloading helps with speed (you don't get the the initial loading hit for a module the first time 
it's used in a specific process) but it can also help with memory on certain OSs. For instance, 
Linux has Copy-On-Write memory so that if you preload modules it saves on actual physical RAM used 
(even though the separate processes think they have their own separate memory spaces).


But remember that each Apache child get's it's own perl interpreter. So if you have a high 
MaxClients you will run out of memory. It's basically Perl Memory * MaxClients for how much RAM 
could be used if your system got busy. This is one of the reasons that most people put a vanilla 
Apache (or something else like squid, lighttpd, varnish, etc) in front as a Proxy. When you do that, 
even if you're running both the proxy and the mod_perl server on the same physical machine you need 
a lot less RAM then if you just ran a mod_perl server trying to do static and dynamic requests.


HTH

--
Michael Peters
Plus Three, LP



Re: Reducing memory usage using fewer cgi programs

2008-10-17 Thread Thomas Hilbig
--- On Fri, 10/17/08, Michael Peters <[EMAIL PROTECTED]> wrote:
> To think about how this works under mod_perl, pretend that
> all of your scripts are put together into 
> 1 larger script and all those "use" statements
> are repeated. Does having multiple "use CGI" 
> statements make your script use more memory? No. CGI.pm is
> only loaded once.

Thanks for clarifying that.  I was never sure if the libraries would be shared 
or placed in their own namespace somehow.


> Preloading helps with speed (you don't get the the
> initial loading hit for a module the first time 
> it's used in a specific process) but it can also help
> with memory on certain OSs. For instance, 
> Linux has Copy-On-Write memory so that if you preload
> modules it saves on actual physical RAM used 
> (even though the separate processes think they have their
> own separate memory spaces).

I'm using linux 2.6.23 with Apache 2.2.8

I did not know about the copy-on-write memory.  I've probably heard the term 
many times, but always assumed it was in regards to a filesystem.  That can 
definitely reduce the memory -- I must move more common libraries to startup.pl


> This is one of the reasons that most people put a vanilla 
> Apache (or something else like squid, lighttpd, varnish,
> etc) in front as a Proxy. When you do that, 
> even if you're running both the proxy and the mod_perl
> server on the same physical machine you need 
> a lot less RAM then if you just ran a mod_perl server
> trying to do static and dynamic requests.
> 

H.  I'm still serving mod_perl programs and static pages from one Apache 
server, with average load of about 1 hit per second.  It's worth looking into 
some of these combinations a little more.

Thanks for your great answers!
Tom

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com