PerlTransHandler Redirect (2.0)

[David Stewart]

How do you replicate the redirect functionality of mod_rewrite in a  
mod_perl 2 PerlTransHandler?


I'm writing a PerlTransHandler to overcome some limitation of  
mod_rewrite and want to redirect requests to canonical URLs in some  
cases (e.g. replicate the functionality of the [R,L] flags in  
mod_rewrite).  What's the best way to do this from the handler?


-David Stewart

Re: decline and fall of modperl?

[Octavian Râsnita]

From: "Joel Bernstein" 
On 23 Mar 2009, at 21:18, Octavian Râsnita wrote:
Can I encrypt some .pm modules in such a way that they couldn't be 
decrypted easier than the PHP files encrypted by Zend Encoder?
If yes, please tell us how, because it would be a really important 
information for the perl developers.



No idea. Can you make this a question against a measurable target?


A pretty simple or medium simple application which is encrypted should not 
be decrypted easy enough to worth the effort of doing this.

The encrypting solution should be very simple to implement.


I'm  not sure what makes you think that the Zend Encoder files are not

recoverable, anecdotal evidence online suggests that they are.

I haven't seen any prove that they can be decrypted easy enough to worth the 
effort.
Modifying the perl or PHP interpreter to save the generated source code 
instead of compiling and executing it, or creating a program that monitors 
the memory and unobfuscate the found source code it is a too big effort and 
it would be much easier to re-create the program instead of decrypting it.


In any case, I've barely heard of a Perl developer who wants this 
feature. Nobody needs encrypted Perl source. It runs in an  interpreter. 
No point, no value, and nobody wants this feature.  Nobody's worked on a 
good implementation because it'd be a waste of  time and resources.


/joel=


The actual perl programmers are not important, because they already have 
their reasons for using perl.
Are you saying that nobody uses Zend Encoder because PHP also runs using an 
interpreter?

I really doubt it.

There are very many software companies that create PHP source code but offer 
just the Zend Encrypted programs and not the source code.
It would be very good if those software companies would know that they could 
do the same programs in perl, and offer the same protection.


I tested Filter::Crypto and it is great!
It is a free code so we can't expect to be as easy to use as Zend Encoder, 
but if we compare it with Zend Encoder, its main problem is that it is not 
so much promoted as Zend Encoder.


I've tried to install it using cpan under Linux, but it gave an error, so I 
needed to force install it.
I've also tried to install it under Windows, but it required Open SSL, so I 
needed to download and compile that software first.
There is a PPM package for Windows and it installs fine, but it doesn't say 
that it requires Open SSL, and after I installed it, I found that it doesn't 
work without installing Open SSL.
Strangely, but after I installed Open SSL under Windows, I was able to 
install it using cpan, and it didn't give any error (unlike under Linux).


I've tested it with a few programs, including the main module of a Catalyst 
application, and it worked very well.


Octavian

Re: Re: decline and fall of modperl?

[Octavian Râşniţă]

From: Mike Bourdon 
> The hidden message here is “the more available senior developers, the more 
> likely available 
> jobs”, an expanding talent pool will lead to an expanding job market. 

I fully agree. What happends in the regions where there are extremely few perl 
programmers, no matter if they are good or bad... we can imagine.
What can we do in order to promote perl in those countries/regions?

There are almost no translated books for learning perl in my country, and the 
editors are not very interested in printing perl books because they won't sell 
well enough, and those few which would be interested would probably pirate them.
Without books and without funds for promoting perl for beeing taught in 
schools, perl won't have any chance in face of DotNet or Java.

> In my humble opinion the perl community needs to embrace the concept of self 
> propagation. For 
> the most part perl/oo perl/mod_perl developers are self taught. Junior or mid 
> level talent (a 
> majority of the talent pool) is passed over as not enough experience. Perhaps 
> this is because 
> they do not push themselves or the roles they come from are User Interface or 
> system ops, 
> people that did not make it in those roles.  This where as an investment of 
> time and effort can > go a long way into building the pool of perl/oo 
> perl/mod_perl developers. Too often everyone is > looking for the instant 
> gratification of a senior level skill set. 

True, but how to do this practicly?
I tried to convince some programmers that Perl is better than PHP, but without 
any success.

Can perl programs run on share hosting web sites? There are some such hosting 
companies that don't even offer perl support, and those who offer it, offer 
just the standard Perl distribution, which don't offer a web framework, or 
templating systems, or ORMS, or form processors, and in these conditions I 
can't tell that perl is so great.

Can they hide the source code? (Because who knows who can get it from those 
free hosting web sites)
I found that they can hide it, but only after installing Open SSL and a perl 
module, which they can't do, because those sites don't offer root access and 
neither shell access.

In order to show them how good is perl, I told them that they would need to 
have a dedicated server, or a VPS, but the cheapest VPS costs much more than a 
shared hosting solution, so in this case perl has another disadvantage.

They've also told me that they know that perl is harder to learn than PHP.
What can I tell them? That it is not true?
Of course that I could have told them that for real good big projects, perl is 
easier to use than PHP, but most of the PHP users don't care about that kind of 
projects. They care about simple projects created from scratch, that don't even 
use a web framework or an ORM or a form processor.

But finally those poor PHP programmers find more jobs than a perl programmer.

Octavian

Re: decline and fall of modperl?

[Carl Johnstone]

Perrin Harkins wrote:
> TicketMaster is Perl.

Ticketmaster switched their UK operation from MS technologies to mod_perl a 
couple of years back too. (Brought it inline with the US side.)

There's a couple of biggies that haven't been mentioned...

BBC
YouPorn (although I don't think they use mod_perl)

You could also ask the question of why Twitter has a shelf of perl books:

http://twitter.com/jobs

;-)

Carl

Re: PerlTransHandler Redirect (2.0)

[Adam Prime]

David Stewart wrote:
How do you replicate the redirect functionality of mod_rewrite in a 
mod_perl 2 PerlTransHandler?


I'm writing a PerlTransHandler to overcome some limitation of 
mod_rewrite and want to redirect requests to canonical URLs in some 
cases (e.g. replicate the functionality of the [R,L] flags in 
mod_rewrite).  What's the best way to do this from the handler?




Here are some obviously simplified, untested examples, i think R is a 
302, but i've included the 301 as well.


for a 302:

use Apache2::RequestRec;
use Apache2::Const -compile => qw(REDIRECT);

sub handler {
my $r = shift
$r->err_headers_out->add(Location => q[your url here]);
return Apache2::Const::REDIRECT;
}

1;


for a 301:

use Apache2::RequestRec;
use Apache2::Const -compile => qw(HTTP_MOVED_PERMANENTLY);

sub handler {
my $r = shift;
$r->err_headers_out->add(Location => q[your url here]);
return Apache2::Const::HTTP_MOVED_PERMANENTLY;
}

1;

Adam

Re: decline and fall of modperl?

[Adam Prime]

Carl Johnstone wrote:

Perrin Harkins wrote:

TicketMaster is Perl.


Ticketmaster switched their UK operation from MS technologies to mod_perl a 
couple of years back too. (Brought it inline with the US side.)


There's a couple of biggies that haven't been mentioned...

BBC
YouPorn (although I don't think they use mod_perl)

You could also ask the question of why Twitter has a shelf of perl books:

http://twitter.com/jobs



facebook mirrors CPAN at http://mirror.facebook.com/ so it seems pretty 
likely that they are using it there too at least for sysadmin type stuff.


Adam

Re: decline and fall of modperl?

[David Ihnen]

Octavian Râşniţă wrote:

From: Mike Bourdon
> The hidden message here is “the more available senior developers, 
the more likely available

> jobs”, an expanding talent pool will lead to an expanding job market.
 
I fully agree. What happends in the regions where there are extremely 
few perl programmers, no matter if they are good or bad... we can imagine.

What can we do in order to promote perl in those countries/regions?
A programmers guild?  Providing training, guidance, and advocacy in the 
market?
There are almost no translated books for learning perl in my country, 
and the editors are not very interested in printing perl books because 
they won't sell well enough, and those few which would be interested 
would probably pirate them.
Without books and without funds for promoting perl for beeing taught 
in schools, perl won't have any chance in face of DotNet or Java.
I think you've got it right there.  We've got to get perl taught in 
schools.  That means perl experts need to be in teaching.  And I have a 
suspicion that perl doesn't appeal to the pure computer scientist very 
well - these are the people who invented hard typed languages, after all.
> In my humble opinion the perl community needs to embrace the concept 
of self propagation. For
> the most part perl/oo perl/mod_perl developers are self taught. 
Junior or mid level talent (a
> majority of the talent pool) is passed over as not enough 
experience. Perhaps this is because
> they do not push themselves or the roles they come from are User 
Interface or system ops,
> people that did not make it in those roles.  This where as an 
investment of time and effort can > go a long way into building the 
pool of perl/oo perl/mod_perl developers. Too often everyone is > 
looking for the instant gratification of a senior level skill set.
 
True, but how to do this practicly?
I tried to convince some programmers that Perl is better than PHP, but 
without any success.
How could they know, if they have never used it?  I was far less 
convinced that PHP was a blight on the face of scripting science until I 
got a job working in it, after all.


Pay them to do it in perl, and after they get through the learning curve 
they'll probably be much happier with it.
Can perl programs run on share hosting web sites? There are some such 
hosting companies that don't even offer perl support, and those who 
offer it, offer just the standard Perl distribution, which don't offer 
a web framework, or templating systems, or ORMS, or form processors, 
and in these conditions I can't tell that perl is so great.
Isn't that to the denigration of the hosting company?  Not supporting 
the framework is no way to support your user base.  As long as the 
dollar is more important than the feature, there's not much we can do 
about this.  These are not things that should be built into the core 
distribution of a language, its the main reason PHP is so awful.
Can they hide the source code? (Because who knows who can get it from 
those free hosting web sites)

Who cares?  Hiding source code is valueless.
I found that they can hide it, but only after installing Open SSL and 
a perl module, which they can't do, because those sites don't offer 
root access and neither shell access.

You get what you pay for I guess.
In order to show them how good is perl, I told them that they would 
need to have a dedicated server, or a VPS, but the cheapest VPS costs 
much more than a shared hosting solution, so in this case perl has 
another disadvantage.
If they care that much about a few $ on a monthly fee for their web 
site, they're not going to pay enough to get a skilled programmer in ANY 
language, to do the programming.

They've also told me that they know that perl is harder to learn than PHP.
What can I tell them? That it is not true?
Yes, but you may or may not be right.  We all agree that coming into 
perl is confusing - too much old data about how to do things is out 
there in the world.  That makes it harder to learn - not because the 
language is harder to learn - but because its not clear what the proper 
way to learn it is.
Of course that I could have told them that for real good big projects, 
perl is easier to use than PHP, but most of the PHP users don't care 
about that kind of projects. They care about simple projects created 
from scratch, that don't even use a web framework or an ORM or a form 
processor.
Sounds like the people who buy expensive fixed-lense cameras, then the 
moment they get interested in photography discover that they could have 
bought an SLR, more capable and flexible, for the same price.  But they 
swore they didn't need the capability to do that when they bought the 
original cameras, so now they're screwed.


The value is that you start with something that will scale, because 
believe it or not, its going to grow - either the one you're working on 
or the next one you're going to work on, leveraging what you learned in 
this job. 

But not everybody 

Re: PerlTransHandler Redirect (2.0)

[David Stewart]

Thanks Adam,

I was pretty sure about returning the constant, but I didn't see where  
the location should go.  Looks like err_headers_out works, thanks.


-David Stewart



On Mar 25, 2009, at 12:36 PM, Adam Prime wrote:


David Stewart wrote:
How do you replicate the redirect functionality of mod_rewrite in a  
mod_perl 2 PerlTransHandler?
I'm writing a PerlTransHandler to overcome some limitation of  
mod_rewrite and want to redirect requests to canonical URLs in some  
cases (e.g. replicate the functionality of the [R,L] flags in  
mod_rewrite).  What's the best way to do this from the handler?


Here are some obviously simplified, untested examples, i think R is  
a 302, but i've included the 301 as well.


for a 302:

use Apache2::RequestRec;
use Apache2::Const -compile => qw(REDIRECT);

sub handler {
   my $r = shift
   $r->err_headers_out->add(Location => q[your url here]);
   return Apache2::Const::REDIRECT;
}

1;


for a 301:

use Apache2::RequestRec;
use Apache2::Const -compile => qw(HTTP_MOVED_PERMANENTLY);

sub handler {
   my $r = shift;
   $r->err_headers_out->add(Location => q[your url here]);
   return Apache2::Const::HTTP_MOVED_PERMANENTLY;
}

1;

Adam

Re: decline and fall of modperl?

[Octavian Râşniţă]

From: David Ihnen 
  Octavian Râşniţă wrote: 
From: Mike Bourdon 
> The hidden message here is “the more available senior developers, the 
more likely available 
> jobs”, an expanding talent pool will lead to an expanding job market. 

I fully agree. What happends in the regions where there are extremely few 
perl programmers, no matter if they are good or bad... we can imagine.
What can we do in order to promote perl in those countries/regions?
  A programmers guild?  Providing training, guidance, and advocacy in the 
market?

There are almost no translated books for learning perl in my country, and 
the editors are not very interested in printing perl books because they won't 
sell well enough, and those few which would be interested would probably pirate 
them.
Without books and without funds for promoting perl for beeing taught in 
schools, perl won't have any chance in face of DotNet or Java.
  > I think you've got it right there.  We've got to get perl taught in 
schools.  That means perl experts need to be in teaching.  And I have a 
  > suspicion that perl doesn't appeal to the pure computer scientist very well 
- these are the people who invented hard typed languages, after all.

  True. I know some guys that love math and all of them love more the strongly 
typed languages.
  Maybe I don't like the strongly typed languages because I attended a 
university and a high school in business and economics.

> I tried to convince some programmers that Perl is better than PHP, but 
without any success.
  > How could they know, if they have never used it?  I was far less convinced 
that PHP was a blight on the face of scripting science until I got a 
  > job working in it, after all.

  They know it because everybody tell them so. Most web sites are done in PHP, 
most job offer for web programmers ask for PHP experience...

  > Pay them to do it in perl, and after they get through the learning curve 
they'll probably be much happier with it.

  I can't tell that in my country there are no software companies specialized 
in perl programming because I don't know all the software companies, but if 
there are some, they could be counted on fingers, and they aren't probably very 
big.
  So who should pay those PHP programmers in order to motivate them?

Can perl programs run on share hosting web sites? There are some such 
hosting companies that don't even offer perl support, and those who offer it, 
offer just the standard Perl distribution, which don't offer a web framework, 
or templating systems, or ORMS, or form processors, and in these conditions I 
can't tell that perl is so great.
  Isn't that to the denigration of the hosting company?  Not supporting the 
framework is no way to support your user base.  As long as the dollar is more 
important than the feature, there's not much we can do about this.  These are 
not things that should be built into the core distribution of a language, its 
the main reason PHP is so awful.

  I agree that those things shouldn't be built in the core distribution, but 
there could be more distributions, like the one offered by ActiveState, or 
Strawberry Perl or others, just as the Zend PHP distribution contains the Zend 
Framework.

  It could be helpful to have a perl distribution that includes the latest 
versions of Template-Toolkit, HTML::Template, Mason, Catalyst, 
CGI::Application, DBIx::Class, Moose, HTML::FormFu and other helpful cpan 
modules.
  A hosting company may want to install that distribution, and it would really 
offer a much better support than the one offered by PHP.
  Yes, those modules won't be updated frequently, but it would be much better 
than simply a CGI.pm support.

  > Can they hide the source code? (Because who knows who can get it from those 
free hosting web sites)
  > Who cares?  Hiding source code is valueless.

  Maybe in your country. In my country 10 euro means too much and actually even 
1 euro means too much if the same thing can be got for free, legally or not.

> I found that they can hide it, but only after installing Open SSL and a 
perl module, which they can't do, because those sites don't offer > root access 
and neither shell access.
  > You get what you pay for I guess.


Well, they can get a free support offered for Zend Optimizer (or how it is 
called the Zend Decoder).

> In order to show them how good is perl, I told them that they would need 
to have a dedicated server, or a VPS, but the cheapest VPS > costs much more 
than a shared hosting solution, so in this case perl has another disadvantage.
  > If they care that much about a few $ on a monthly fee for their web site, 
they're not going to pay enough to get a skilled programmer in ANY > > 
language, to do the programming.


Of course they care. If the same thing can be done cheaper using PHP, they 
will surely choose PHP.
(The quality doesn't matter, because here the things are so fast changing, 
and the easin

Re: decline and fall of modperl?

[David Ihnen]

Octavian Râşniţă wrote:

*From:* David Ihnen 

 

> I tried to convince some programmers that Perl is better than
PHP, but without any success.

> How could they know, if they have never used it?  I was far less
convinced that PHP was a blight on the face of scripting science
until I got a
> job working in it, after all.

They know it because everybody tell them so. Most web sites are done 
in PHP, most job offer for web programmers ask for PHP experience...
Then they don't know, they just repeat what others say.  So I guess all 
we can do is repeat what we know from experience, and hope that others 
repeat it too...?


> Pay them to do it in perl, and after they get through the
learning curve they'll probably be much happier with it.

I can't tell that in my country there are no software companies 
specialized in perl programming because I don't know all the software 
companies, but if there are some, they could be counted on fingers, 
and they aren't probably very big.

So who should pay those PHP programmers in order to motivate them?
Somebody who wants a program, and is smart enough to know that the 
engineers are better choosers of the software language than they are.  
Any consultant, firm, company, consultant, or contractor can pay, and 
spend his time, to learn perl.  They simply have to make the decision to 
do so.  Perhaps you could do so.



Can perl programs run on share hosting web sites? There are some
such hosting companies that don't even offer perl support, and
those who offer it, offer just the standard Perl distribution,
which don't offer a web framework, or templating systems, or
ORMS, or form processors, and in these conditions I can't tell
that perl is so great.

Isn't that to the denigration of the hosting company?  Not
supporting the framework is no way to support your user base.  As
long as the dollar is more important than the feature, there's not
much we can do about this.  These are not things that should be
built into the core distribution of a language, its the main
reason PHP is so awful.

I agree that those things shouldn't be built in the core distribution, 
but there could be more distributions, like the one offered by 
ActiveState, or Strawberry Perl or others, just as the Zend PHP 
distribution contains the Zend Framework.
 
It could be helpful to have a perl distribution that includes the 
latest versions of Template-Toolkit, HTML::Template, Mason, Catalyst, 
CGI::Application, DBIx::Class, Moose, HTML::FormFu and other helpful 
cpan modules.
A hosting company may want to install that distribution, and it would 
really offer a much better support than the one offered by PHP.
Yes, those modules won't be updated frequently, but it would be much 
better than simply a CGI.pm support.
Now you're talking about something that just about anybody (even you) 
could do if they put their mind to it, don't you think?  Its just 
creating a distribution, after all.  Its just not a very perlish thing 
to do to limit.  Maybe it would be cool if you could have an interface 
that lets you request and install the latest CPAN module on the shared 
servers without having root or shell.  It might be even better, not 
limiting anything.


> Can they hide the source code? (Because who knows who can get it
from those free hosting web sites)
> Who cares?  Hiding source code is valueless.

Maybe in your country. In my country 10 euro means too much and 
actually even 1 euro means too much if the same thing can be got for 
free, legally or not.
You taking it and using it doesn't impact anything, and the companies 
have to understand that.  Its just some ideas and organization, 
pretending you can keep other people from knowing how you did something 
just makes it less supportable by anybody - good software can be bad 
software just because its obfuscated like that.  Those who matter will 
actually pay for your software because they want the support and 
customization that comes with it.  If they're not going to pay up front, 
they're more likely to pay later - keeping them from using the software 
at all won't help.  So why obfuscate or worry about it?



> I found that they can hide it, but only after installing Open
SSL and a perl module, which they can't do, because those sites
don't offer > root access and neither shell access.

> You get what you pay for I guess.

Well, they can get a free support offered for Zend Optimizer (or how 
it is called the Zend Decoder).
Free support as in open-source community stuff?  Or as in a commercial 
company spending their time to help you with something that they don't 
get paid for?



In order to show them how good is perl, I told them that they
would need to have a dedicated server, or a VPS, but the cheapest
VPS costs much more than a shared hosting solution, so in this
case perl has another disadva

encrypting perl

[Foo JH]

Octavian Râsnita wrote:
> The actual perl programmers are not important, because they already have
> their reasons for using perl.
> Are you saying that nobody uses Zend Encoder because PHP also runs using
> an interpreter?

I'm changing the topic of your discussion because it's gone tangent to
the subject...

Business people love the idea of their intellectual property (IP) being
protected by way of code encryption. Try telling them their money-making
code is 'in the open, but everyone's doing it too'. Not exactly a warm
fuzzy feeling.

This topic has been resurfaced from time to time. I think the bottom
line is: there is no supported form of code encryption for Perl. Some
people try to partially compile the code into bytecode, and distribute
with that. But I don't think it's officially supported.

The forward step in this may lie with Perl6. Unfortunately while Parrot
1.0 has JUST been launched, Perl6 isn't, and it'd take quite a while
before we get there. It's still NOT encoded, just compiled into a more
cryptic form, just like Java and the rest.

Re: decline and fall of modperl?

[Foo JH]

David Ihnen wrote:
> I think you've got it right there.  We've got to get perl taught in
> schools.  That means perl experts need to be in teaching.  And I have a
> suspicion that perl doesn't appeal to the pure computer scientist very
> well - these are the people who invented hard typed languages, after all.
In the academia the general directive in choosing a language would be
something to this effect:
1. teach modern language concepts, such as OO
2. minimise the learning curve by way of something easy to teach, easy
to learn without having to figure out all the details of programming
3. introduce the students to a language that will make them attractive
to the general market

You probably have a feel why Perl isn't a strong choice given these
objectives.

Perl was popular in the days when the people who go into software
courses do it for the sake of pure interest. These are the people who
are contented with Emacs or VIM, as long as they get to work with the codes.

Half of today's CompSci students are people who stumble in because they
haven't figured things out in life. The problem is made worse by Visual
Studio and Eclipse. I remember how Java was a painful experience before
someone finally put up a IDE that aids code visualisation and object
description.

My personal belief is that Perl MUST move with the times. It's an
incredibly uphill task to change the market's mindset without a
commercial budget.

I place my bets on Perl6. It's regrettably a slow process, but it's the
only sexy thing available on hand.

> Pay them to do it in perl, and after they get through the learning curve
> they'll probably be much happier with it.
Half the developers aren't the type who can appreciate a good language.
They can develop intensively for 5 years and they STILL haven't figured
out what is Regex. Trust me on this!

> Who cares?  Hiding source code is valueless.
You haven't met the China folks have you? :)

There's outright protection, there's deterrance, and there's leaving the
door open for every bad boy to muck it up.