Re: separating C from V in MVC

[Rob Nagler]

Andy Wardley writes:
> Because Perl is a general purpose programming language.  TT implements
> a general purpose presentation language.  A different kettle of fish
> altogether.

These are the reserve words of TT:

GET CALL SET DEFAULT INSERT INCLUDE PROCESS WRAPPER 
IF UNLESS ELSE ELSIF FOR FOREACH WHILE SWITCH CASE
USE PLUGIN FILTER MACRO PERL RAWPERL BLOCK META
TRY THROW CATCH FINAL NEXT LAST BREAK RETURN STOP 
CLEAR TO STEP AND OR NOT MOD DIV END

Looks an awful lot like the same keywords in any general-purpose
programming language.

> It's like asking why XML has different syntax and semantics from
> Perl.

Well, if you read the XSLT spec and then look at an XSLT program,
you'll see a lot of verbosity and a lot of general purpose constructs
like variables, conditionals, and loops.  I haven't done much with
XSLT, but I do know you can get it in an infinite loop.  That seems
pretty general purpose to me.

I think the rule is: if you can solve Towers of Hanoi in the language,
its general purpose enough.  True formatting languages, such as,
Scribe do not contain general-purpose constructs, so you couldn't
solve the Towers of Hanoi.  HTML is another good example (ignoring

Re: tutorials (was: Re: rfc Apache::Dynagzip)

[Stas Bekman]

Slava Bizyayev wrote:
> It's going to be something like "Features of Content Compression for
> Different Web Clients" for Part IV: Client side facts and bugs. We'll be
> able to discuss details next week.

Sounds great, looking forward to it.

Probably the best post it here first, so we can get it reviewed and 
commented on before we add it to the docs.

__
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: Perl 5.6.1 INIT blocks

[Stas Bekman]

D.J. Miller II wrote:
> Howdy,
> 
> I'm trying to find out if Perl 5.6.1 INIT blocks are supported by
> mod_perl.  By "supported," I mean that the INIT blocks are executed each
> time the scripts containing them are run under mod_perl, not just at
> compilation time like BEGIN blocks.

In fact they aren't supported at all, when you try to run them from 
inside requests -- you will get an error:

   Too late to run INIT block at ...

> In the "ToDo" file of the mod_perl 1.26 distribution I find:
> 
> ---
> POSSIBLE NEW FEATURES
> ---
> 
> - require +ExecCGI for  in .htaccess, etc.
> 
> [...]
> 
> - CHECK blocks? [Michael J Schout <[EMAIL PROTECTED]>]
>   INIT blocks?  [T.J. Mather <[EMAIL PROTECTED]>]
> 
> In the 1.27 distribution there's no "ToDo" file, but no mention of INIT
> or CHECK block support in the "Changes" file, either.

ToDo has moved into the STATUS file.


__
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: DBI Bug

[Stas Bekman]

> t/REPORT don't print any problem

Udlei, please read the info at the URL I gave to you again. It says:

Whenever you send a bug report make sure to include the information 
about your system by doing the following:

   % cd modperl-2.0
   % t/REPORT > mybugreport

Also it explains how to get the backtrace (which is very essential):
http://perl.apache.org/release/docs/2.0/user/help/help.html#Resolving_Segmentation_Faults

__
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: rfc Apache::Dynagzip

[Slava Bizyayev]

From: "Igor Sysoev" <[EMAIL PROTECTED]>


> mod_deflate had been used for one year on several popular Russian sites
> without problems so I think the main browsers have good gzip support.

I'm not quite familiar with the mod_deflate code:
Should we consider that every web client uses the same code (and rules) to
decompress gzip & deflate?
Does deflate use the same to gzip data format?

> > That's why I believe it is better to have one simple common rule in all
> > compression modules (like an Accept-Encoding header), and a flexible
FixUp
> > handler, which should control the $r->header_in('Accept-Encoding') prior
to
> > compression handler.
>
> Fixup handler is too early for this.

Sorry, I don't get what you mean?

> I can host it on my site. I already have list of browser gzip/deflate
> capabilites and bugs in mod_deflate Russian documentation.
> I need simply translate it to English.

I've seen it.

Thanks,
Slava

Re: tutorials (was: Re: rfc Apache::Dynagzip)

[Slava Bizyayev]

It's going to be something like "Features of Content Compression for
Different Web Clients" for Part IV: Client side facts and bugs. We'll be
able to discuss details next week.

Thanks,
Slava

- Original Message -
From: "Stas Bekman" <[EMAIL PROTECTED]>
To: "Per Einar Ellefsen" <[EMAIL PROTECTED]>
Cc: "Valerio_Valdez Paolini" <[EMAIL PROTECTED]>; "Slava
Bizyayev" <[EMAIL PROTECTED]>; "mod_perl Mailing List"
<[EMAIL PROTECTED]>
Sent: Wednesday, June 05, 2002 11:44 AM
Subject: tutorials (was: Re: rfc Apache::Dynagzip)


> Per Einar Ellefsen wrote:
> > At 15:36 05.06.2002, Valerio_Valdez Paolini wrote:
> >
> >> On Tue, 4 Jun 2002, Slava Bizyayev wrote:
> >>
> >> > I don't know should it be a kitchen of every system administrator, or
> >> > somebody could volunteer to serve the public web site about the
current
> >> > conditions of different web clients and recommended masks?.. I can't
> >> host it
> >> > on my devl4, because it is a development machine. That would be
> >> better to
> >> > find some stable place, like mod_perl, or apache project ;-).
> >>
> >> Can you provide a compatibility list? I think that the new mod_perl
site
> >> is looking for new articles, may be the first part of Apache::Dynagzip
> >> man page is a good candidate... You could add also known bugs and
> >> features. But I cannot decide what goes on mod_perl site :)
> >
> >
> > Just like I would have said it myself :-) We're clearly looking for
> > information, and I was especially watching this thread for possible
> > inclusion. We have a nice place to do this, it's in our "Browser bugs"
> > section. Depending on the size of the document, it might go there or in
> > its own doc. Anyway, we welcome any submissions. Format is standard Pod.
> > See
> >
http://cvs.apache.org/viewcvs.cgi/modperl-docs/admin/style.pod?rev=1.8&conte
nt-type=text/vnd.viewcvs-markup
> > for style information, but don't worry too much about that, we'll fix
> > that as we go.
>
> I just want to add some clarifications to Per Einar comment.
>
> Are we looking for not strictly mod_perl but closely related material,
> which matters to the majority of mod_perl programmers?
>
> The short answer:
>
> Tutorials -> yes
> manpages  -> no
> articles  -> take23.org
>
> The long answer:
>
> Tutorials cover some interesting topics using several implementations.
> Tutorials are pretty much static and don't require much maintenance. We
> heartly welcome these. The ongoing discission of MVC is a good example
> of a tutorial candidate, templating comparison and *generic* tips and
> tricks are other ones.
>
> Manpages, which aren't the core module are not very welcome at this
> moment, as they usually require high level of maintenance, and we have
> hardly resources to cope with perl.apache.org. So at least for now,
> manpages aren't welcome.
>
> If you have feature tutorials, either submit those to take23.org or any
> other online zine. perl.com is looking for such articles. so does
> apacheweek.com. probable there are others.
>
> The new perl.apache.org is not a dump place for docs. The more
> irrelevant stuff we throw there the less added value the site will have,
> the harder it'll be to find something and the whole idea of expanding
> docs will do more bad than good. So new tutorials are definitely
> welcome, but re-read the first para to see the definition of a good
> candidate and so the existing tutorials at:
> http://perl.apache.org/release/docs/tutorials/index.html
> before submitting your tutorial. If your idea of tutorial doesn't fit
> into perl.apache.org's tutorial's idea, we will gladly link to it.
>
> ---
>
> Now back to the topic. If you can submit to us known problems with
> browsers and solutions that would be great. But please don't submit the
> Apache::Dynagzip manpage.
>
> __
> 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: rfc Apache::Dynagzip

[Slava Bizyayev]

Deal. I'll take care about this by the weekend and let you know when ready.

Thanks,
Slava

- Original Message -
From: "Per Einar Ellefsen" <[EMAIL PROTECTED]>
To: "Valerio_Valdez Paolini" <[EMAIL PROTECTED]>
Cc: "Slava Bizyayev" <[EMAIL PROTECTED]>; "mod_perl Mailing List"
<[EMAIL PROTECTED]>
Sent: Wednesday, June 05, 2002 10:23 AM
Subject: Re: rfc Apache::Dynagzip


> At 15:36 05.06.2002, Valerio_Valdez Paolini wrote:
>
> >On Tue, 4 Jun 2002, Slava Bizyayev wrote:
> >
> > > I don't know should it be a kitchen of every system administrator, or
> > > somebody could volunteer to serve the public web site about the
current
> > > conditions of different web clients and recommended masks?.. I can't
> > host it
> > > on my devl4, because it is a development machine. That would be better
to
> > > find some stable place, like mod_perl, or apache project ;-).
> >
> >Can you provide a compatibility list? I think that the new mod_perl site
> >is looking for new articles, may be the first part of Apache::Dynagzip
> >man page is a good candidate... You could add also known bugs and
> >features. But I cannot decide what goes on mod_perl site :)
>
> Just like I would have said it myself :-) We're clearly looking for
> information, and I was especially watching this thread for possible
> inclusion. We have a nice place to do this, it's in our "Browser bugs"
> section. Depending on the size of the document, it might go there or in
its
> own doc. Anyway, we welcome any submissions. Format is standard Pod. See
>
http://cvs.apache.org/viewcvs.cgi/modperl-docs/admin/style.pod?rev=1.8&conte
nt-type=text/vnd.viewcvs-markup
> for style information, but don't worry too much about that, we'll fix that
> as we go.
>
>
> --
> Per Einar Ellefsen
> [EMAIL PROTECTED]
>
>
>

LoadModule [Updated Problem]

[Prachait Saxena]

Hello All,

I am using Apache 1.3.23 (Win32) + Win98 Conf.
and I would like to install SSL in this.

First I would like to tell you that, I had already read the documentation 
by Apache as well as OpenSSL. 

I am trying to LoadModule in the apache as.

LoadModule ssl_module   modules/mod_ssl.so #[SSL]
and I am getting a strange error as 

Cannot Load Module (PATH)/modules/mod_ssl.so (31) A device attached to 
the system in not functioning

Well, I have one TVTuner Card on my machine which is not working. I tries 
this also after removing this cared from the machine. 
One More this I did not have any netwrokcard on my machine, 

And i did not think that by about two reasons this probelm may occur.

One more problem in LoadModule of PHP and MySql is [ I mean the error is ]
Cannot Load Module (PATH)/modules/libphp4.dll (1157)  One of the library 
files need to run the application not found.

Strange 

I have downloaded both apache and modules from the site.

I have two questions:

Can any one suggest me why i am getting such types of error ?

Will I have to compile the apache ? IF yes then suggest me a good 
documentation.

Will I have to compile the modules for PHP4 and SSL then How ?
Any Good Documentation ?


Bye and Have a nice day 

Prachait Saxena

WebMaster
SitesOnTesting.Com

If you do for other's !
Other's will do for you !!

Visit me at http://www.sitesontesting.com/prachait

Re: eating memory on FreeBSD

[Alvar Freude]

Hi,

-- Doug MacEachern <[EMAIL PROTECTED]> wrote:

> dso should be fine with 1.26 or 1.27, provided you are using Perl 5.6.1
> or  higher.  5.005_03 still has leakage.

no, as mentioned some months ago in the list, on FreeBSD with mod_perl 1.26
as DSO and Perl 5.6.1 there are big leaks: every mod_perl which should be
shared between the forked shilds seems to be allocated new (and additional)
every restart (including graceful) again and at startup twice.

Tested with:

  - Manual build perl 5.6.1 from sources, mod_perl 1.26 from sources as
DSO, 
Apache from the ports.
  
  - Perl 5.6.1 from ports, mod_perl 1.26 (DSO) from ports, Apache from ports

  - Perl 5.005... from FreeBSD base system and all from ports.


All with different options, threads off, usemymalloc off and on, ... 


I didn't found any configuration, with which it worked and doesn't eat all
the Memory which should be shared every (re)start.


If I can help in fixing this bug, I'll do this! :-)


Ciao
  Alvar

-- 
// Stop Censorship! http://www.odem.org/informationsfreiheit/en/
// Filter your internet http://www.odem.org/insert_coin/imkp2001.html
// Blast!   http://www.a-blast.org/
// Alvar:   http://alvar.a-blast.org/

Re: Separating Aspects (Re: separating C from V in MVC)

[Sam Tregar]

On Wed, 5 Jun 2002, Andy Wardley wrote:

> In TT, you would usually pre-declare a particular format in a config
> file, pre-processed templates, or some other "global" style document.
> e.g.
>
>   [% USE money = format('%.02f') %]
>
> In your main page templates you would do something like this:
>
>   [% money(order.total) %]
>
> Then you can change the money format in one place and your designers
> don't have to worry about sprintf formats.

In HTML::Template::Expr:

  sub money { sprintf "%.02f", $_[0] }
  HTML::Template::Expr->register_function(money => \&money);

Then in the template:

  

Now, I don't use HTML::Template::Expr.  I think it's generally not such a
good idea.  But it's there if you want it...

> See, the problem is that MVC is just one particular decomposition.  It's
> generally a good one because application, data and presentation are typically
> the three biggest aspects that you want to separate.  However, it doesn't
> take into account any of the other dozen or so aspects that you might want
> to model in your system.  Nowhere in MVC or any other Design Pattern does
> it tell you to define all your URLs in one place in case you ever need to
> change them en masse.  You have to think of that all by yourself.  MVC is
> no substitute for thinking

Oh, absolutely.  MVC is just a framework, and it only addresses a subset
of the problems in any large system.  I think that's actually a strength.
I would be deeply suspicious of any paradigm that claimed to solve ALL my
problems.  I prefer small, simple (tools|paradigms) that do one thing and
do it well.

> I've seen far too many example of people who didn't pass objects into their
> templates, didn't embed Perl code, or didn't do this or that because they
> thought that it might violate the MVC principal.

Here!

> The end result was that they jumped through hoops and made the system
> more complex than it needed to be for the sake of "purity".

It was?  I don't think this is the only result.  It might be that these
people you've observed were just the hoop-jumping, complexifying types.
I've built quite a number of large systems without embedded Perl and object
variables without excessive hoop-jumping.

Here's my theory: the best usage of most templating systems are virtually
indistinguishable and all result in reasonably maintainable systems.
However, the bad usage of some templating systems is much worse than
others.  Also, the general usage of a templating system, even by otherwise
bright people, tends more towards the bad than the good.

Thus my solution: a templating system that simply will not allow you to
put anything significantly complicated in the template.  You can't.  If
you want complexity you'll just have to put it in the code, where it
belongs.  That's HTML::Template in a nutshell.

>   [% silver.bullet %] isn't the answer by itself...

Here here.  Neither is  but I'd rather get shot
with mine than yours!

-sam

Apache::SubRequest::run segfaulting

[dbohling]

Hey list,

To be able to pass some notes across php subrequest calls which in turn 
call a mod_perl handlers we've overriden Apache::SubRequest::run() in 
startup.pl like so:

### save the original method
*NFN::run_save = \&Apache::SubRequest::run;

## build our custom version
sub NFN::run_custom {
my $subr = shift(@_);
## copy our notes into the subrequest
my $parent_notes = $subr->main->notes();
for my $key (keys(%$parent_notes)) {
if ($key =~ /^NFN_/) {
$subr->notes($key, $parent_notes->{$key});
}
}
my @retval = ();
## i don't know if run() returns differently in
## scalar vs. array context, so i've split up the
## call here.  (normally, i would just say
## return NFN::run_save() but i can't return until later
if(wantarray) {
## call the original method
@retval = NFN::run_save($subr, @_);
}
else {
## call the original method
my $retval = NFN::run_save($subr, @_);
@retval = ($retval);
}
## copy our notes back into the parent
my $child_notes = $subr->notes();
for my $key (keys(%$child_notes)) {
if ($key =~ /^NFN_/) {
$subr->main->notes($key, $child_notes->{$key});
}
}
return wantarray ? @retval : $retval[0];
}
### make calls to Apache::Subrequest::run get handled by
### our custom method.
*Apache::SubRequest::run = \&NFN::run_custom;


This works as intended but has a peculiar side effect. My development 
machine's browser, mozilla 1.0 rc3, segfaults the apache process when 
serving a particular page on our sites. My laptop has the same exact 
build and does not do this at all. I've seen 1 machine in our office do 
this on IE 6.0 , but only on a different page. In all cases when apache 
segfaults, about 1/4 of the html for the page comes out. This 1/4 is 
served by a php page which is called via $subr->run() from a registry 
script. The php subrequest finishes normally, but the registry script 
causes the segfault at the next print command after the $subr->run() call.



Watching my log files I can see that other machines are also segfaulting 
apache processes. This behavior stops when I remove our modification to 
the run method. The absolute bizarre thing is that almost all pages on 
our site work exactly the same way, call the same php files, but only 
one segfaults apache from my browser, but on the IE machine, it's a 
different page that segfaults.

Anyhow, I've managed to grab a backtrace from when my browser hits the 
server:

Program received signal SIGSEGV, Segmentation fault.
0x08138498 in ap_bwrite ()
(gdb) bt
#0  0x08138498 in ap_bwrite ()
#1  0x08147572 in ap_rwrite ()
#2  0x08127e31 in XS_Apache_write_client ()
#3  0x08127c52 in XS_Apache_print ()
#4  0x0819c12c in Perl_pp_entersub ()
#5  0x08157645 in S_call_body ()
#6  0x0815721b in perl_call_sv ()
#7  0x081570a1 in perl_call_method ()
#8  0x08197a16 in Perl_pp_print ()
#9  0x08196a58 in Perl_runops_standard ()
#10 0x08157654 in S_call_body ()
#11 0x08157431 in perl_call_sv ()
#12 0x081570a1 in perl_call_method ()
#13 0x0811d8e2 in perl_call_handler ()
#14 0x0811d1f9 in perl_run_stacked_handlers ()
#15 0x0811bca9 in perl_handler ()
#16 0x08139191 in ap_invoke_handler ()
#17 0x08149a6c in process_request_internal ()
#18 0x08149aee in ap_process_request ()
#19 0x08142984 in child_main ()
#20 0x08142b00 in make_child ()
#21 0x08142c36 in startup_children ()
#22 0x081431fb in standalone_main ()
#23 0x081439e8 in main ()
#24 0x400ef507 in __libc_start_main (main=0x8143680 , argc=2, 
ubp_av=0xbad4,
 init=0x8073d5c <_init>, fini=0x81da5f0 <_fini>, 
rtld_fini=0x4000dc14 <_dl_fini>,
 stack_end=0xbacc) at ../sysdeps/generic/libc-start.c:129




-- 
--
Daniel Bohling
NewsFactor Network

Perl 5.6.1 INIT blocks

[D.J. Miller II]

Howdy,

I'm trying to find out if Perl 5.6.1 INIT blocks are supported by
mod_perl.  By "supported," I mean that the INIT blocks are executed each
time the scripts containing them are run under mod_perl, not just at
compilation time like BEGIN blocks.

In the "ToDo" file of the mod_perl 1.26 distribution I find:

---
POSSIBLE NEW FEATURES
---

- require +ExecCGI for  in .htaccess, etc.

[...]

- CHECK blocks? [Michael J Schout <[EMAIL PROTECTED]>]
  INIT blocks?  [T.J. Mather <[EMAIL PROTECTED]>]

In the 1.27 distribution there's no "ToDo" file, but no mention of INIT
or CHECK block support in the "Changes" file, either.

Anyone know if there's a version of mod_perl that has this INIT block
support?


 James Miller in Austin, Texas

Re: Doing security for backend applications

[Ask Bjoern Hansen]

On Tue, 4 Jun 2002, Ken Miller wrote:

[...]
> So, php application requests would bounce from the proxy server to the mod
> perl server to the php server.

You could also make it so it's only when requests needs to be
authenticated they go to the mod_perl server.

Something like having the php server forward authentication requests
to the mod_perl server; but support the same cookie format would be
relatively simple.

> This is all related to a single sign-on environment - once the user has
> signed on an encrypted cookie will contain the application security
> information used to authorize the user int the various applications.

at perl.org we have made it so authentication requests gets
forwarded, and then we have an internal interface for the various
servers can validate and migrate authentication cookies.

You should be able to find documentation on how passport.com does
it; if nothing else then on the pages where it's described why their
implementation was insecure at some point. ;-)

 - ask

-- 
ask bjoern hansen, http://ask.netcetera.dk/   !try; do();

Re: Doing security for backend applications

[Ken Miller]

Please ignore this message.  My mail client was misconfigured (! in my email
address), and I expected the message to bounce.  I sent another message this
morning that was very similar to this one, and now this one shows up.  Darn
it!

Cheers!

-klm.

- Original Message -
From: "Ken Miller" <[EMAIL PROTECTED]>
To: "Modperl" <[EMAIL PROTECTED]>
Sent: Tuesday, June 04, 2002 3:56 PM
Subject: Doing security for backend applications


> Let's say I have the following configuration:
>
> 1. Front end proxy server (no mod_perl)
> 2. Back end application server (mod_perl)
> 3. Back end application server (php)
>
> Now, *all* application requests are passed to the mod_perl server (yes,
> including the php requests).  Performing security checks for all the
> applications on the mod_perl server is easy via a few simple handlers.
> However, I also want to *transparently* handle high-level application
access
> security for the applications served from the php server using the same
> perl/db modle I use in the mod perl server.
>
> So, php application requests would bounce from the proxy server to the mod
> perl server to the php server.
>
> Is this workable? I currently use mod_rewrite to proxy the requests to the
> mod_perl server, and I'm assuming I would have to do something similar for
> the php server.  However, I'm not all that sure how to do this, since I
> don't think mod_rewite will work the way I expect - I need to configure a
>  but mod_rewrite doesn't work with . Or does it?
>
> In case anyone is wondering, I'm working on constructing a dynamic
front-end
> portal that will gate through to various applications, some developed in
> house, others obtained from third parties - the clients wants to perform a
> global security check before getting to the application, hence the stuff
> that I'm creating.
>
> This is all related to a single sign-on environment - once the user has
> signed on an encrypted cookie will contain the application security
> information used to authorize the user int the various applications.
>
> Many thanks!
>
> -klm.
>
>
>

Doing security for backend applications

[Ken Miller]

Let's say I have the following configuration:

1. Front end proxy server (no mod_perl)
2. Back end application server (mod_perl)
3. Back end application server (php)

Now, *all* application requests are passed to the mod_perl server (yes,
including the php requests).  Performing security checks for all the
applications on the mod_perl server is easy via a few simple handlers.
However, I also want to *transparently* handle high-level application access
security for the applications served from the php server using the same
perl/db modle I use in the mod perl server.

So, php application requests would bounce from the proxy server to the mod
perl server to the php server.

Is this workable? I currently use mod_rewrite to proxy the requests to the
mod_perl server, and I'm assuming I would have to do something similar for
the php server.  However, I'm not all that sure how to do this, since I
don't think mod_rewite will work the way I expect - I need to configure a
 but mod_rewrite doesn't work with . Or does it?

In case anyone is wondering, I'm working on constructing a dynamic front-end
portal that will gate through to various applications, some developed in
house, others obtained from third parties - the clients wants to perform a
global security check before getting to the application, hence the stuff
that I'm creating.

This is all related to a single sign-on environment - once the user has
signed on an encrypted cookie will contain the application security
information used to authorize the user int the various applications.

Many thanks!

-klm.

Re: RPM for apache/mod_perl/mod_ssl

[Christof Damian]

On Wed, 05 Jun 2002, fliptop wrote:
> i have an rpm for apache 1.3.22, mod_perl 1.26, and mod_ssl 2.8.5
> that i run on redhat 6.2.  i'd be glad to give you the .src (or the
> .rpm if you also run redhat 6.2) if you would like it.
> 
> or, i could just give you the .spec if you'd like to build a new rpm 
> with the latest versions.

i got one for redhat 7.0, i am in the progress to update it to the
current versions of apache/mod_perl/mod_ssl though.

christof
-- 
Christof Damian 
Technical Director, guideguide ltd. 

Apache::TalkBack

[Gabriel C Millerd]

got any ideas on what this would do if i wrote it? basically the goal is
to do the same thing netscape's talk back does. (whatever that is)

so i would store a data::dump of the $ENV, apache request ($r) and the cgi
param ($r), a Carp like $@ of the bomb ... as well as the cgi name,
and timestamp.

then the user in charge of that cgi could look up those issues?

---
Gabriel C. Millerd |   All for one, one for all, that is out device.
 Script Monkey | -Alexander Dumas the Elder, The Three Musketeers
   |

Re: DBI Bug

[Tim Burden]

Perhaps it's not clear whether v. 1.99 is actually a 2.x
Sorry, I find the numbering confusing, but have everything working fine with
1.26

- Original Message -
From: "Udlei Nattis" <[EMAIL PROTECTED]>
To: "Stas Bekman" <[EMAIL PROTECTED]>
Cc: "Perrin Harkins" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, June 05, 2002 3:39 PM
Subject: Re: DBI Bug


> hi
>
> this problem is very very very persistent
>
> httpd.conf
>
> PerlModule DBI # THIS IS THE PROBLEM
>
> PerlModule Apache::Registry
> 
> SetHandler perl-script
> PerlHandler Apache::Registry
> Options ExecCGI
> allow from all
> PerlSendHeader On
> 
>
> i try all
> rebuild modperl witch modperl 1.99dev02, dev03cvs, using perl 5.7.3,
5.8RC1 with Thread and without Thread
>
> t/REPORT don't print any problem
>
> BUT if i have PerlModule DBI in httpd.conf i receive:
> [root@nattis bin]# ./apachectl start
> ./apachectl: line 192: 27461 Segmentation fault  $HTTPD
> ./apachectl start: httpd could not be started
> [root@nattis bin]#
>
> when i remove PerlModule:
> [root@nattis bin]# ./apachectl start
> ./apachectl start: httpd started
> [root@nattis bin]#
>
> i using last version of DBI
>
> bye
>
> nattis
>
>
>
> Stas Bekman wrote:
>
> > Perrin Harkins wrote:
> >
> >> Udlei Nattis wrote:
> >>
> >>> hi, sorry my english ;)
> >>>
> >>> when i add this line in httpd.conf
> >>>
> >>> PerlModule DBI
> >>>
> >>> or
> >>>
> >>> use DBI(); in startup.conf
> >>>
> >>> apache dont start, i receive this error:
> >>>
> >>> /usr/local/apache-2.0/bin/apachectl: line 192: 12547 Segmentation
> >>> fault  $HTTPD
> >>> /usr/local/apache-2.0/bin/apachectl start: httpd could not be started
> >>>
> >>> i test it in
> >>> Apache 2.0/Perl 5.8.0RC1/Modperl 1.99.02/03
> >>> Apache 2.0/Perl 5.7.3/Modperl 1.99.02/03
> >>> Apache 2.0/Perl 5.6.1/Modperl 1.99.02/03
> >>> Apache 2.0-cvs/All Perls/All Modperls
> >>
> >>
> >>
> >> It definitely works with the Apache 1.x/mod_perl 1.x/perl 5.6.1
> >> combo. Maybe someone else can verify that they've run DBI under
> >> mod_perl 2?
> >
> >
> > Works for me with 1.99, but see below.
> >
> >> You might need to use the pre-fork MPM when using DBI, depending on
> >> how well your database driver works with threads.  You should also
> >> make sure you compile all of these with the same compiler, to ensure
> >> compatibility between libraries.
> >
> >
> > Folks, when you see a question like this, don't waste your time
> > guessing in the dark without having the so needed details posted
> > first. Just point them here:
> >
http://perl.apache.org/release/docs/2.0/user/help/help.html#Reporting_Proble
ms
> >
> >
> > You don't have to search for this item, it's in the shortcuts menu on
> > the left.
> >
> > __
> > 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: DBI Bug

[wsheldah]

By that do you mean DBI 1.24? That was just released a day or two ago IIRC.
Just checking,

Wes



Udlei Nattis <[EMAIL PROTECTED]> on 06/05/2002
03:39:00 PM

To:   Stas Bekman <[EMAIL PROTECTED]>
cc:   Perrin Harkins <[EMAIL PROTECTED]>,
  [EMAIL PROTECTED] (bcc: Wesley
  Sheldahl/Lex/Lexmark)
Subject:  Re: DBI Bug



i using last version of DBI

bye

nattis

Re: DBI Bug

[Udlei Nattis]

hi

this problem is very very very persistent

httpd.conf

PerlModule DBI # THIS IS THE PROBLEM

PerlModule Apache::Registry

SetHandler perl-script
PerlHandler Apache::Registry
Options ExecCGI
allow from all
PerlSendHeader On


i try all
rebuild modperl witch modperl 1.99dev02, dev03cvs, using perl 5.7.3, 5.8RC1 with 
Thread and without Thread

t/REPORT don't print any problem

BUT if i have PerlModule DBI in httpd.conf i receive:
[root@nattis bin]# ./apachectl start
./apachectl: line 192: 27461 Segmentation fault  $HTTPD
./apachectl start: httpd could not be started
[root@nattis bin]# 

when i remove PerlModule:
[root@nattis bin]# ./apachectl start
./apachectl start: httpd started
[root@nattis bin]# 

i using last version of DBI

bye

nattis



Stas Bekman wrote:

> Perrin Harkins wrote:
>
>> Udlei Nattis wrote:
>>
>>> hi, sorry my english ;)
>>>
>>> when i add this line in httpd.conf
>>>
>>> PerlModule DBI
>>>
>>> or
>>>
>>> use DBI(); in startup.conf
>>>
>>> apache dont start, i receive this error:
>>>
>>> /usr/local/apache-2.0/bin/apachectl: line 192: 12547 Segmentation 
>>> fault  $HTTPD
>>> /usr/local/apache-2.0/bin/apachectl start: httpd could not be started
>>>
>>> i test it in
>>> Apache 2.0/Perl 5.8.0RC1/Modperl 1.99.02/03
>>> Apache 2.0/Perl 5.7.3/Modperl 1.99.02/03
>>> Apache 2.0/Perl 5.6.1/Modperl 1.99.02/03
>>> Apache 2.0-cvs/All Perls/All Modperls
>>
>>
>>
>> It definitely works with the Apache 1.x/mod_perl 1.x/perl 5.6.1 
>> combo. Maybe someone else can verify that they've run DBI under 
>> mod_perl 2?
>
>
> Works for me with 1.99, but see below.
>
>> You might need to use the pre-fork MPM when using DBI, depending on 
>> how well your database driver works with threads.  You should also 
>> make sure you compile all of these with the same compiler, to ensure 
>> compatibility between libraries.
>
>
> Folks, when you see a question like this, don't waste your time 
> guessing in the dark without having the so needed details posted 
> first. Just point them here:
> http://perl.apache.org/release/docs/2.0/user/help/help.html#Reporting_Problems 
>
>
> You don't have to search for this item, it's in the shortcuts menu on 
> the left.
>
> __
> 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: Setting the Content-Type for displaying a gif

[Robert Landrum]

On Wed, Jun 05, 2002 at 04:38:26PM +0200, [EMAIL PROTECTED] wrote:
> Hello, 
> 
> I have a problem with setting the correct content-type under mod_perl
> with mason. I use mason with the mod_perl args_method.
> I want to get a .gif out of a database and print it
> in a window, but all i get is binary junk. I tried to set the correct
> content-type but when i look at the page source i can't see it. 
> 
> Here the relevant extract from my source: 
> 
> my $sth = $db->prepare("select attachment from table");
> $sth->execute();
> # following three lines should set content-type
> #$r->header_out('Content-Type' => 'image/gif');
> #$r->headers_out->add('Content-Type' => 'image/gif');
> $r->content_type("image/gif");
> my ($att) = $sth->fetchrow_array();
> $m->out($att); 
> 

You're real close here

$r->content_type("image/gif");
$r->send_http_header;
$r->print($att);
$m->abort(200);





> What am i doing wrong? 
> 

You actually need to bypass mason for this.  It's unfortunate that mason 
doesn't have some better image content type recoginition and do the right
thing (hint, hint :).

Rob

[ANNOUNCE] release of LaBrea::Tarpit 1.03

[Michael Robinton]

LaBrea::Tarpit is an enhanced reporting module that generates web pages
showing the activity of worm and trojan attacks agains your netblock. It
uses Tom Liston's "LaBrea" daemon as a front end to provide data for the
reports.

New Features
* paginated reporting, much nicer than the BIG long page

*stubs for yet to be announced tracking of ICMP
  and UDP scans w/ DShield reporting

* remote daemon operation -- daemon will run on remote host and can
  be interrogated to retrieve data for web-scripts. See my demo sites
at:
  http://scans.bizsystems.net/  -- runs on the local host
  http://probes.bizsystems.net/  -- is in another city,

  different primary network supplier. Both web sites are hosted on
  the same web server and report in real time.

other interesting stuff added in recent releases:

dshield reporting -- mail_dshield.pl
  reports new attacks to dshield.org
old bad guy reports -- tell_me.pl
  lets you know when an attacking host has been
  your tarpit for a predetermined length of time
other sites reports -- web_scan.pl
  shows a summary of the activity of other sites running LaBrea::Tarpit

Grab the new release from the download site, there is a button on the
demo site to reach it.

If anyone has a good idea what category all this should be classified
under, I'll submit it to CPAN.

enjoy,
Michael

Re: RPM for apache/mod_perl/mod_ssl

[Fran Fabrizio]

Thanks Stas for that link, but none of those have mod_ssl and I'm not 
skilled enough with RPM to make that heavy of an adjustment, to be honest.

I think I'll take a gander at fliptop's specs and see if they are close 
enough to do what I need.  

Thanks all!

-Fran

Stas Bekman wrote:

> Fran Fabrizio wrote:
>
>>
>> We're currently struggling for an easy way to distribute our 
>> apache/mod_perl/mod_ssl-based application to our data center folks 
>> who are in a different state and whom we must presume know nothing 
>> about apache, mod_perl or mod_ssl and are capable of nothing more 
>> complicated than using RPM to install/update a package. As such, does 
>> there exist such a thing as an RPM that installs apache with mod_perl 
>> AND mod_ssl enabled?  I presume this would also have to include 
>> openssl.  I can only imagine what a pain it would be to create this 
>> beast, but if it's been done, I'd like to give it a try.
>>
>> I have used my limited experience with RPM to try to build this kind 
>> of thing, but so far the closest I've gotten is to have an RPM that 
>> includes the four tarballs with a shell script to compile them on the 
>> target machine.  Of course this really isn't in the spirit of RPM and 
>> also, fails miserably when the target machine is a hardened machine 
>> with no compiler, for example. :-)
>>
>> Does such a thing exist, and what are some pros and cons of going 
>> this route?
>>
>> Personally, I would hate to have to rely on an RPM like this, not 
>> least because I'd have to learn how to modify it if it doesn't meet 
>> our needs, but we need to make the application install as easy as 
>> possible for the data center folks.  Thoughts?
>
>
> Take an existing src RPM (.spec) and adjust it the way you want. Here 
> are some RPMs:
> http://perl.apache.org/release/download/binaries.html#RedHat_Linux
>
> __
> 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: RPM for apache/mod_perl/mod_ssl

[fliptop]

Jon Robison wrote:

> fliptop, I'll take a copy of that spec file, if you don't mind!!!


i just posted it to my website, and also included a .spec for building 
perl 5.6.1:

http://www.peacecomputers.com/perl-5.6.1.spec.txt
http://www.peacecomputers.com/apache-modperl-1.3.22.spec.txt

feel free to share modifications!

Re: tutorials (was: Re: rfc Apache::Dynagzip)

[Perrin Harkins]

Stas Bekman wrote:
> The ongoing discission of MVC is a good example 
> of a tutorial candidate

Incidentally, I already wrote a fair amount on this subject in the 
eToys-related tutorial:
http://perl.apache.org/release/docs/tutorials/scale_etoys/etoys.html#Code_Structure

There's a diagram, code examples, etc.  I wasn't planning to write a 
spearate MVC one because I've already said most of it there.

- Perrin

Re: RPM for apache/mod_perl/mod_ssl

[Stas Bekman]

Fran Fabrizio wrote:
> 
> We're currently struggling for an easy way to distribute our 
> apache/mod_perl/mod_ssl-based application to our data center folks who 
> are in a different state and whom we must presume know nothing about 
> apache, mod_perl or mod_ssl and are capable of nothing more complicated 
> than using RPM to install/update a package. 
> As such, does there exist such a thing as an RPM that installs apache 
> with mod_perl AND mod_ssl enabled?  I presume this would also have to 
> include openssl.  I can only imagine what a pain it would be to create 
> this beast, but if it's been done, I'd like to give it a try.
> 
> I have used my limited experience with RPM to try to build this kind of 
> thing, but so far the closest I've gotten is to have an RPM that 
> includes the four tarballs with a shell script to compile them on the 
> target machine.  Of course this really isn't in the spirit of RPM and 
> also, fails miserably when the target machine is a hardened machine with 
> no compiler, for example. :-)
> 
> Does such a thing exist, and what are some pros and cons of going this 
> route?
> 
> Personally, I would hate to have to rely on an RPM like this, not least 
> because I'd have to learn how to modify it if it doesn't meet our needs, 
> but we need to make the application install as easy as possible for the 
> data center folks.  Thoughts?

Take an existing src RPM (.spec) and adjust it the way you want. Here 
are some RPMs:
http://perl.apache.org/release/download/binaries.html#RedHat_Linux

__
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: RPM for apache/mod_perl/mod_ssl

[Jon Robison]

fliptop, I'll take a copy of that spec file, if you don't mind!!!

--Jon Robison


fliptop wrote:
> 
> Fran Fabrizio wrote:
> 
> >
> > We're currently struggling for an easy way to distribute our
> > apache/mod_perl/mod_ssl-based application to our data center folks who
> > are in a different state and whom we must presume know nothing about
> > apache, mod_perl or mod_ssl and are capable of nothing more complicated
> > than using RPM to install/update a package.
> > As such, does there exist such a thing as an RPM that installs apache
> > with mod_perl AND mod_ssl enabled?  I presume this would also have to
> > include openssl.  I can only imagine what a pain it would be to create
> > this beast, but if it's been done, I'd like to give it a try.
> 
> what o/s and version are you running?
> 
> i have an rpm for apache 1.3.22, mod_perl 1.26, and mod_ssl 2.8.5 that i
> run on redhat 6.2.  i'd be glad to give you the .src (or the .rpm if you
> also run redhat 6.2) if you would like it.
> 
> or, i could just give you the .spec if you'd like to build a new rpm
> with the latest versions.

tutorials (was: Re: rfc Apache::Dynagzip)

[Stas Bekman]

Per Einar Ellefsen wrote:
> At 15:36 05.06.2002, Valerio_Valdez Paolini wrote:
> 
>> On Tue, 4 Jun 2002, Slava Bizyayev wrote:
>>
>> > I don't know should it be a kitchen of every system administrator, or
>> > somebody could volunteer to serve the public web site about the current
>> > conditions of different web clients and recommended masks?.. I can't 
>> host it
>> > on my devl4, because it is a development machine. That would be 
>> better to
>> > find some stable place, like mod_perl, or apache project ;-).
>>
>> Can you provide a compatibility list? I think that the new mod_perl site
>> is looking for new articles, may be the first part of Apache::Dynagzip
>> man page is a good candidate... You could add also known bugs and
>> features. But I cannot decide what goes on mod_perl site :)
> 
> 
> Just like I would have said it myself :-) We're clearly looking for 
> information, and I was especially watching this thread for possible 
> inclusion. We have a nice place to do this, it's in our "Browser bugs" 
> section. Depending on the size of the document, it might go there or in 
> its own doc. Anyway, we welcome any submissions. Format is standard Pod. 
> See 
> 
>http://cvs.apache.org/viewcvs.cgi/modperl-docs/admin/style.pod?rev=1.8&content-type=text/vnd.viewcvs-markup
> 
> for style information, but don't worry too much about that, we'll fix 
> that as we go.

I just want to add some clarifications to Per Einar comment.

Are we looking for not strictly mod_perl but closely related material, 
which matters to the majority of mod_perl programmers?

The short answer:

Tutorials -> yes
manpages  -> no
articles  -> take23.org

The long answer:

Tutorials cover some interesting topics using several implementations. 
Tutorials are pretty much static and don't require much maintenance. We 
heartly welcome these. The ongoing discission of MVC is a good example 
of a tutorial candidate, templating comparison and *generic* tips and 
tricks are other ones.

Manpages, which aren't the core module are not very welcome at this 
moment, as they usually require high level of maintenance, and we have 
hardly resources to cope with perl.apache.org. So at least for now, 
manpages aren't welcome.

If you have feature tutorials, either submit those to take23.org or any 
other online zine. perl.com is looking for such articles. so does 
apacheweek.com. probable there are others.

The new perl.apache.org is not a dump place for docs. The more 
irrelevant stuff we throw there the less added value the site will have, 
the harder it'll be to find something and the whole idea of expanding 
docs will do more bad than good. So new tutorials are definitely 
welcome, but re-read the first para to see the definition of a good 
candidate and so the existing tutorials at:
http://perl.apache.org/release/docs/tutorials/index.html
before submitting your tutorial. If your idea of tutorial doesn't fit 
into perl.apache.org's tutorial's idea, we will gladly link to it.

---

Now back to the topic. If you can submit to us known problems with 
browsers and solutions that would be great. But please don't submit the 
Apache::Dynagzip manpage.

__
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: RPM for apache/mod_perl/mod_ssl

[fliptop]

Fran Fabrizio wrote:

> 
> We're currently struggling for an easy way to distribute our 
> apache/mod_perl/mod_ssl-based application to our data center folks who 
> are in a different state and whom we must presume know nothing about 
> apache, mod_perl or mod_ssl and are capable of nothing more complicated 
> than using RPM to install/update a package. 
> As such, does there exist such a thing as an RPM that installs apache 
> with mod_perl AND mod_ssl enabled?  I presume this would also have to 
> include openssl.  I can only imagine what a pain it would be to create 
> this beast, but if it's been done, I'd like to give it a try.


what o/s and version are you running?

i have an rpm for apache 1.3.22, mod_perl 1.26, and mod_ssl 2.8.5 that i 
run on redhat 6.2.  i'd be glad to give you the .src (or the .rpm if you 
also run redhat 6.2) if you would like it.

or, i could just give you the .spec if you'd like to build a new rpm 
with the latest versions.

Re: rfc Apache::Dynagzip

[Igor Sysoev]

On Tue, 4 Jun 2002, Slava Bizyayev wrote:

> Dear Valerio, Alvar, and Igor,
> Thank you very much for your attention to Apache::Dynagzip.
> It is on CPAN now:
> 
> The uploaded file Apache-Dynagzip-0.04.tar.gz has entered CPAN as
> file: $CPAN/authors/id/S/SL/SLAVA/Apache-Dynagzip-0.04.tar.gz
> size: 24939 bytes
> md5: 586610ffdd35cd1ceceaba4796fd6212
> 
> I've just fixed a few typos and updated README for this version.
> Now I'm back in our discussion.
> 
> I believe the questions, which we began to discuss yesterday with Valerio
> privately should go public being helpful for others too. Especially, seeing
> that they are similar to Alvar's interests.
> 
> I feel this discussion very important, but this time it is not about the
> Dynagzip itself. Indeed, it is about the implementation of gzip compression
> in most common view.
> 
> You know, there are 6 open source modules/packages for the web content
> compression available in the World (in alphabetic order):
> 
> ·Apache::Compress
> ·Apache::Dynagzip
> ·Apache::Gzip
> ·Apache::GzipChain
> ·mod_deflate

I should note that there are two unrelated mod_deflate modules - my one for
Apache 1.3 and Apache2's one.

> ·mod_gzip

> On other hand, you know of-course, that the compression is used rarely in
> practice to date. My own observations show that there are only few content
> providers, who compress their traffic. I would mention Oracle as the leader,
> which covers a significant percent of its on-line documentation with gzip
> compression (looks like a static approach). On Yahoo there are few pages
> gzipped only. Even the US governmental sites do not use gzip. Why?
> 
> Because it is not that simple to implement the web compression to date. The
> success of the compression implementation depends on quality of client side
> software. I would not consider the efforts of browser vendors sufficient
> these days. We know many bugs. Others are still hidden. We can't fix them.
> To adjust a web server appropriately is a common problem for any of
> mentioned compression modules.

mod_deflate had been used for one year on several popular Russian sites
without problems so I think the main browsers have good gzip support.

> That's why I believe it is better to have one simple common rule in all
> compression modules (like an Accept-Encoding header), and a flexible FixUp
> handler, which should control the $r->header_in('Accept-Encoding') prior to
> compression handler.

Fixup handler is too early for this.

> I don't know should it be a kitchen of every system administrator, or
> somebody could volunteer to serve the public web site about the current
> conditions of different web clients and recommended masks?.. I can't host it
> on my devl4, because it is a development machine. That would be better to
> find some stable place, like mod_perl, or apache project ;-).

I can host it on my site. I already have list of browser gzip/deflate
capabilites and bugs in mod_deflate Russian documentation.
I need simply translate it to English.

Igor Sysoev
http://sysoev.ru

RPM for apache/mod_perl/mod_ssl

[Fran Fabrizio]

We're currently struggling for an easy way to distribute our 
apache/mod_perl/mod_ssl-based application to our data center folks who 
are in a different state and whom we must presume know nothing about 
apache, mod_perl or mod_ssl and are capable of nothing more complicated 
than using RPM to install/update a package.  

As such, does there exist such a thing as an RPM that installs apache 
with mod_perl AND mod_ssl enabled?  I presume this would also have to 
include openssl.  I can only imagine what a pain it would be to create 
this beast, but if it's been done, I'd like to give it a try.

I have used my limited experience with RPM to try to build this kind of 
thing, but so far the closest I've gotten is to have an RPM that 
includes the four tarballs with a shell script to compile them on the 
target machine.  Of course this really isn't in the spirit of RPM and 
also, fails miserably when the target machine is a hardened machine with 
no compiler, for example. :-)

Does such a thing exist, and what are some pros and cons of going this 
route?

Personally, I would hate to have to rely on an RPM like this, not least 
because I'd have to learn how to modify it if it doesn't meet our needs, 
but we need to make the application install as easy as possible for the 
data center folks.  Thoughts?

Thanks,
Fran

Using apache for access control for third party web apps

[Ken Miller]

The saga continues...

I've been tasked with developing a single-signon environment for a suite of
web applications, some developed in house, and others obtained from third
parties; others are still waiting to be developed.  The framework I'm
developing will, when a user signs in, end up setting a cookie which
contains security credentials that will allow access to various parts of the
system.  The cookie will be encrypted, or perhaps just contain a session id.

I currently use a proxy/app server configuration, with the app server
running (what else) mod_perl.  I will be adding additional servers to host
third party applications, which may or may not be running mod_perl.  In one
case, I know for sure that one of the additional servers will be running
PHP.

The framework I'm developing will *only* perform application access control,
based on an application tree structure.  The access control handler will
take the cookie and the security requirements for the portion of the
application tree being accessed and determine if access is allowed or not.
It's up to the application itself to perform authorization (authentication
has already been done if the cookie is present).

Since access control is performed in mod_perl, I need the proxy to forward
all requests to the mod_perl server.  For applications hosted on the same
mod_perl instance, access control is easy, since the request will naturally
flow from handler to handler.  Where I'm having difficulty is figuring out
how the mod_perl server will perform access control for third party
applications that reside on different servers.

I guess what I'm asking is this:

How can I configure an apache instance to perform access control, and
proxying of the request to another server if the access control says the
request is ok?  From my reading, mod_proxy will only allow top-level
configuration, not  configuration.  Ditto for mod_rewrite.  Do I
have to implement my own proxying?

I would like the end result to be something like this:

proxy server --> access control server -> application servers

where the access control server is a mod_perl server, and an application
server is one of either mod_perl or PHP or whatever.

Is what I'm suggesting doable, or just plain silly?  Is there a better way?

Cheers!

-klm.

ANNOUNCE: Apache::Gallery 0.4

[Michael Legart]

Hello

It has been a while since the last release of Apache::Gallery,
but here is 0.4.

Thanks alot to the people who contributed with patches!

The changes include:

- Round height and width to integers when scaling to avoid
  widths like 640x479.393939393939 (Me)
- Regenerate scaled pictures and thumbnails if the original
  image has changed, the image.rotate file has been added or
  changed or if the copyright image was added og changed. (Me)
- Don't show files starting with "." in the thumbnail index (Yann Kerhervé)
- Made thumbnailsizes configurable with the GalleryThumbnailSize
  option. (Me)
- Print "Unknown" instead of $INFO in the imageinfo field if
  unable to find any EXIF information. (Me)
- Added perldoc documentation of the module and a installationguide. (Me)
- Always list directories before images (Me)
- Allow textfiles (ie, robots.txt) (Me)
- Fixed a bug where $FILES was printed instead of "Empty directory"
  if directory contained unsupported files (.txt, .htaccess etc) (Me)
- New templates where folders doesn't get displayed one on each line (Thomas 
Kjaer)
- Works without a VirtualHost now (Does not use DocumentRoot) (Peter Breton) 
- New option GalleryWrapNavigation to enable a new feature in the
  pictureview where "Next" at the end displays the first picture etc
(Peter Breton/Me)
- New option AllowOriginal for the user to be able to download the
  original picture, not enabled by default (Thomas Eibner)
- TIFF and PPM support (Thomas Eibner)
- Initial movie support - download movie clips (Rene Joergensen)

Remember to read the UPGRADE document when upgrading from an older
version.

Apache::Gallery 0.4 can be downloaded http://apachegallery.dk/ or
your local CPAN mirror.

Michael

Re: rfc Apache::Dynagzip

[Per Einar Ellefsen]

At 15:36 05.06.2002, Valerio_Valdez Paolini wrote:

>On Tue, 4 Jun 2002, Slava Bizyayev wrote:
>
> > I don't know should it be a kitchen of every system administrator, or
> > somebody could volunteer to serve the public web site about the current
> > conditions of different web clients and recommended masks?.. I can't 
> host it
> > on my devl4, because it is a development machine. That would be better to
> > find some stable place, like mod_perl, or apache project ;-).
>
>Can you provide a compatibility list? I think that the new mod_perl site
>is looking for new articles, may be the first part of Apache::Dynagzip
>man page is a good candidate... You could add also known bugs and
>features. But I cannot decide what goes on mod_perl site :)

Just like I would have said it myself :-) We're clearly looking for 
information, and I was especially watching this thread for possible 
inclusion. We have a nice place to do this, it's in our "Browser bugs" 
section. Depending on the size of the document, it might go there or in its 
own doc. Anyway, we welcome any submissions. Format is standard Pod. See 
http://cvs.apache.org/viewcvs.cgi/modperl-docs/admin/style.pod?rev=1.8&content-type=text/vnd.viewcvs-markup
 
for style information, but don't worry too much about that, we'll fix that 
as we go.


-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Setting the Content-Type for displaying a gif

[oklein]

Hello, 

I have a problem with setting the correct content-type under mod_perl
with mason. I use mason with the mod_perl args_method.
I want to get a .gif out of a database and print it
in a window, but all i get is binary junk. I tried to set the correct
content-type but when i look at the page source i can't see it. 

Here the relevant extract from my source: 

my $sth = $db->prepare("select attachment from table");
$sth->execute();
# following three lines should set content-type
#$r->header_out('Content-Type' => 'image/gif');
#$r->headers_out->add('Content-Type' => 'image/gif');
$r->content_type("image/gif");
my ($att) = $sth->fetchrow_array();
$m->out($att); 

What am i doing wrong? 

Bye, Olaf 

Re: separating C from V in MVC

[Andy Wardley]

On Mon, Jun 03, 2002 at 09:49:59PM -0600, Rob Nagler wrote:
> Another concern I have about Template Toolkit (and other template
> languages) is that it has its own syntax and semantics for data and
> control structures distinct from Perl.  Why isn't Perl good enough?

Because Perl is a general purpose programming language.  TT implements
a general purpose presentation language.  A different kettle of fish
altogether.  

It's like asking why XML has different syntax and semantics from Perl.

> This is what Template Toolkit has become imo, and so the
> argument about template languages being "easier than Perl" is
> specious.  Rather, they become harder, because you have to think in
> two languages instead of one.

Perhaps, but I personally don't have any trouble switching between 
numerous different domain specific languages.  In the last hour, for
example, I've been using these: 

  Perl
  Perl regular expressions
  SQL
  XML 
  Javascript
  Template Toolkit

I find it easier to have a little language which is tailored to the task
at hand.  The problem comes when you try and grow your little language
into a general purpose programming language.  I've tried to resist that
temptation in TT, but I readily admit that feature creep is a common
trait in such systems.


A

Re: separating C from V in MVC

[Andy Wardley]

On Fri, May 31, 2002 at 12:21:45PM -0400, Jesse Erlbaum wrote:
> It's the "addition tricks" which bug me out.  With those two words you
> establish the mother of all slippery slopes to architecture oblivion.  

True.  And in your Perl code you can also write all sorts of dangerous code
that totally breaks your MVC architecture.  What stop you from doing that?

> IMHO, any system built on Template Toolkit (unless it is small and always
> managed by the same programmer) will ultimately devolve in just the same way
> as a Server Page system.

In my experience, that's not the case.  It will devolve just as fast as 
you allow it to.


A

Re: rfc Apache::Dynagzip

[Valerio_Valdez Paolini]

On Tue, 4 Jun 2002, Slava Bizyayev wrote:

> I don't know should it be a kitchen of every system administrator, or
> somebody could volunteer to serve the public web site about the current
> conditions of different web clients and recommended masks?.. I can't host it
> on my devl4, because it is a development machine. That would be better to
> find some stable place, like mod_perl, or apache project ;-).

Can you provide a compatibility list? I think that the new mod_perl site
is looking for new articles, may be the first part of Apache::Dynagzip
man page is a good candidate... You could add also known bugs and
features. But I cannot decide what goes on mod_perl site :)

Bye, Valerio



 Valerio Paolini, 
--
 what is open-source about? Learn, and then give back

Re: separating C from V in MVC

[Andy Wardley]

On Thu, May 30, 2002 at 05:42:23PM -0400, Jesse Erlbaum wrote:
> It has been my experience that applying a design pattern such as MVC is not
> a panacea.
[...]
> My point:  My
> code isn't good because I apply some "pattern" to it.  It may be good, and
> it may resemble a pattern -- but those two things are largely coincidental.

Absolutely!

> The View, in a web application, is really the HTML output.  Generally, this
> will be your templating system.  Optimally, the View avoids *ALL*
> application logic.  At my company we use HTML::Template because it strongly
> enforces the separation of View from Controller -- e.g., HTML from code.  (I
> realize that many of you prefer other HTML templating systems, but I still
> contend that HTML::Template is the most effective system for truly
> separating HTML from code.  And it's damn fast, too.)

Enforcing a clear separation of View from Controller is not the same thing
as not calling code from templates.  It is perhaps the most misunderstood
point about MVC and templates.

There's nothing wrong with calling a subroutine or object method from a 
template as long as:

  * the code perform a presentation function (not an application one)
  * the code doesn't have any side-effects on the model or other controllers

You can also call code to perform lazy data-loading as Perrin has already
mentioned, but that does require a little more thought on the part of your
back-end designers to ensure that things continue to behave as planned.

Or you can break all the rules if you know what you're doing.  I break
the rules all the time when I'm knocking together a few quick and dirty 
web pages, generating an SQL report, or a Postscript page showing a
graphical distribution of the first thousand prime numbers.  MVC is 
good for big web sites, but overkill for quick hacks.  

A

Re: separating C from V in MVC

[Andy Wardley]

On Mon, Jun 03, 2002 at 08:09:12AM -0600, Rob Nagler wrote:
> > [% FILTER font('my_first_name_font') %]
> > ... some text, possibly with other template directives in it...
> > [% END %]
> 
> One of the reasons Perl is popular is its idioms.  Having to say
> something in three lines is not as idiomatic as one line.  It takes a
> lot of discipline to use it everywhere.  In other words, I don't think
> the above is more comfortable than:
> 
> String(['User.first_name'], 'my_first_name_font');

So write it that way:

  [% String(user.first_name, my_first_name_font) %]

Just define the 'String' template variable to be a reference to your
'String' sub.

I do agree with what you're saying, however.  Perl is good, so don't
try and replace it with a markup language.


A

Separating Aspects (Re: separating C from V in MVC)

[Andy Wardley]

Continuing from the thread on the modperl mailing list:

On Sun, Jun 02, 2002 at 05:04:01PM -0400, Sam Tregar wrote:
> > I don't think the standard HTML::Template has support for formatting
> > numbers, dates, etc.
> 
> And thank the sweet lord it doesn't!  HTML::Template is a "do one thing
> and do it well" module.  If you want routines for formatting "numbers,
> dates, etc." then CPAN has just what you need.

I (mostly) consider formatting of numbers, etc., to be a presentation 
issue, not a programming one.  That's why TT supports this kind of 
thing in the templates (or in the code if you prefer).  

Of course, the fact that it's a module/object is entirely hidden.  TT 
abstracts the front end templates from the backend implementation, so
that the HTML designers don't have to know if a data structure is 
implemented as a hash, object, or subroutine, it just does the right 
thing.

This allows the developers to worry about implementing a back-end system
in the best way possible and the front-end designers to just use it.

> HTML::Template::Expr may present a solution to this particular desire,
> although it isn't one I've come across.  How often are HTML designers
> fiddling with numeric formats?  Are they really HTML designers if they can
> deal with, say, a printf-style format string?

In TT, you would usually pre-declare a particular format in a config
file, pre-processed templates, or some other "global" style document.
e.g.

  [% USE money = format('%.02f') %]

In your main page templates you would do something like this:

  [% money(order.total) %]

Then you can change the money format in one place and your designers
don't have to worry about sprintf formats.  

If you prefer to write your own formatting subroutine you can do it 
like so:

  my $vars = {
 money => sub { return sprintf("%.02f", shift) };
 order => {
 total => 22.95,
 }
  };

  $template->process($file, $vars) || die $template->error();

Guess what?  You don't have to change any of the templates.  They still 
use the same syntax:

  [% money(order.total) %]

This is abstraction.  Not to be confused with MVC which is one particular
architecture well suited to GUI applications.  Blindly applying MVC without
understanding the real issues (abstraction of front/back ends, separation of 
concerns, don't repeat yourself, etc.) is likely to build a system which is 
highly fragmented.  Maintenance becomes harder because everything is split 
up into many different pieces and it becomes difficult to see the wood for 
the trees.  

Aspect oriented programming teaches us that as soon as you decompose a 
system into a particular structure you inevitably fragments aspects which
cut across the system.  I have seen this in close and painful detail over the 
past few months while helping to build a very strictly partitioned MVC 
architecture system for Fotango(.com).  We're using TT for presentation, 
Openframe for the application pipeline/dispatch and a custom data backend 
called Vx.

Despite our best intentions, this web site doesn't neatly fall into 
clearly defined chunks of model, application and view.  Well, actually,
those parts do split down quite nicely.  But then you look at localisation,
for example, and we find there is localisation required in the data backend, 
localisation required in the applications and localisation required in the 
templates.  Thus, localisation is an aspect which cuts across the system.
By building a strict MVC we've fragmented localisation and have to trawl
through hundreds of different files to localise the site.  

Another example is that different countries running their localised versions
of this web site will want to change the URLs.  Where the english version
uses /product/shirt/red.html, the french version should instead be 
/produit/chemise/rouge.html, for example.  Again, these URLs are (currently)
embedded throughout the system and making any changes to them is a painful 
process involved many files spread across the M, the V and the C.  In an 
ideal world, English and French would just be different views of the same
model.  Alas, it's never that easy because the chances are that parts of
the model and parts of the controllers will also need changing.  

See, the problem is that MVC is just one particular decomposition.  It's 
generally a good one because application, data and presentation are typically
the three biggest aspects that you want to separate.  However, it doesn't
take into account any of the other dozen or so aspects that you might want
to model in your system.  Nowhere in MVC or any other Design Pattern does
it tell you to define all your URLs in one place in case you ever need to 
change them en masse.  You have to think of that all by yourself.  MVC is 
no substitute for thinking and it often encourages the opposite, lulling 
you into a false sense of security by the fact that you think you're doing 
the Right Thing.

I've seen far too many example of people who didn