Re: ANNOUNCE: Apache::ASP 2.63 released
wow, welcome back Joshua! That's great news בתאריך יום ה׳, 15 במרץ 2018, 18:41, מאת Josh Chamas <j...@chamas.com>: > Hi All! > > Apache::ASP 2.63 has finally been released! Apache::ASP provides an Active > Server Pages port to the Apache Web Server with Perl scripting. > > The main issue fixed is the ability to work with Apache 2.4 and mod_perl > 2.0. > > You can install from CPAN, and also https://metacpan.org/pod/Apache::ASP > > > > CHANGES: > > + fixed $r->connection()->remote_ip() to use useragent_ip(), then > client_ip() > access for Apache 2.4 > > + Added section ``raw'' to MailErrors.inc to debug POSTs without > form fields > > - MailErrorsHTML now uses monospaced fonts for errors. Easier on > the eyes and more informative > > - Added a clumsy regex to avoid header longer than 70 chars > > - removed deprecated "Extra" module references from Makefile.PL and > Bundle::Apache::ASP::Extra, > including Apache::Filter, Apache::SSI, Bundle::XML, XML::Sablotron, and > Tie::TextDir > > > > FUTURE: > > Tsirkin Evgeny has done work for Apache::ASP to work under PSGI/Plack. To > get > this please see this work under the Apache-ASP-PSGI-Support in SourceForge. > > > https://sourceforge.net/p/apache-asp/code/HEAD/tree/branches/Apache-ASP-PSGI-Support/ > > Regards, > > Josh Chamas > > - > To unsubscribe, e-mail: asp-unsubscr...@perl.apache.org > For additional commands, e-mail: asp-h...@perl.apache.org > >
Re: Apache::ASP under PSGI
Just for a reference Since I am unable to get any response & get the module fixes into CPAN. I have put it on github That's for anybody who might want to use it in future https://github.com/tsirkin/Apache-ASP Thanks Evgeny
Re: Apache::ASP Mod_perl
I have created a branch of apache::asp to work on Plack/PSGI It worked nicely and is in repository . I just didn't have a time to document it but i will be back to it once i do. And i an actually looking for testers . And ASP have it pluses ,like page based navigation (and not MVC) if that's what you want. Anyway it seems like Cris is trying to run VB using this module and it will not work, Cris, this is a module for running perl in ASP like fashion .VB will not work Evgeny On Sat, Jul 18, 2015 at 12:08 AM, Warren Young war...@etr-usa.com wrote: On Jul 17, 2015, at 1:16 PM, Cris Boisvert c...@usai.net wrote: Trying to get apache with asp and mod perl working. On what platform? Specifically, which versions of Apache, mod_perl, and Perl are you using? I get this error in the logs. [asp] [1349] [error] error compiling test.asp: Can't modify constant item in scalar assignment at /var/www/site/test.asp line 16, at EOF -- , /usr/share/perl5/Apache/ASP.pm line 1466 I’ve never seen that one. It means Apache::ASP couldn’t compile an *.asp or *.inc file, but I couldn’t say why. What I can tell you is that Apache::ASP really hasn’t been updated significantly since the days when mod_perl was the standard way to deploy Perl web apps, which hasn’t been true for quite some time now. The Perl world has moved on to Plack/PSGI and FastCGI instead, and mod_perl has been left to bit-rot. It’s gotten to the point that RHEL 7 and its derivatives no longer even include mod_perl. While all of this can be worked around, I can’t recommend going to the trouble if you don’t have a legacy code base to get working again, and not even then in most cases. We ported our web app to Dancer. It was quite a bit of work, but we’re very happy with the new framework. I wrote a longish review of Dancer as compared to Apache::ASP here on this list about a year back: http://goo.gl/kDQB5b - To unsubscribe, e-mail: asp-unsubscr...@perl.apache.org For additional commands, e-mail: asp-h...@perl.apache.org
Re: Migrate existing Apache::ASP code from mod_perl to mod_fcgid?
On Thu, May 22, 2014 at 10:55 PM, Warren Young war...@etr-usa.com wrote:
Routing is more than just an abstraction between the implementation level
and the presentation to the browser. It forces you to consider your
logical URL structure.
My Apache::ASP code just growed, like Topsy. One page at a time, with no
consideration of the interfaces exposed by the other pages. There was
consistency of design only to the extent that there was code copying, and
then in decreasing fashion with respect to time, as the cloned pages
diverged.
As soon as I started developing a system of routes in the Dancer port, I
realized that I had an API. It was sitting there the whole time, never
identified in the Apache::ASP form, but there it was in the Dancer code,
clear as day. Once I'd formally extracted it, I spent a day redesigning it
the way it should always have been. The correct design popped right out,
obvious as a green sky.
This happens because you have to describe your URL structure to Dancer,
one URL per line. Many fit in a single screen of text, so patterns jump
out at you.
Example in Dancer pseudocode:
get '/' = ...
get '/login' = ...
get '/logout' = ...
prefix '/app' = sub {
get 'page1' =
get 'page2' =
};
prefix '/api' = sub {
del 'foo/:id' = ...
get 'foo/:id' = ...
post 'foo' = ...
put 'foo' = ...
get 'bar/:id' = ...
...same as foo...
};
The story this route structure tells is clear:
1. First you go to the top level page, which perhaps has a Log In link or
button to send you to the /login page.
2. The /login page creates a session and bounces you to /app when you log
in successfully.
3. There's a button or link somewhere that sends you to /logout, which
destroys your session and sends you back to / or /login.
4. The app does CRUD-y things to foo and bar objects through
/api/{foo,bar}, creating via PUT, reading via GET, updating via POST, and
deleting via DELETE. GET and DELETE require a record ID to tell the
handler what to operate on, while PUT and POST must be fairly complex in
what they will accept, so that the parameters cannot be marked as required
in the route structure.
It's kind of like that Fred Brooks quote, Show me your flowcharts and
conceal your tables, and I shall continue to be mystified. Show me your
tables, and I won’t usually need your flowcharts; they’ll be obvious.
What you describe looks much like REST.
Is it good? I don't know .I guess it is a matter of taste .
Personally ,I like it sometimes and sometimes I wish it would just let me
do what I want and don't force to do the right thing.
The possible problem of this approach - you need a reverse routing API.
How do you link to an action in a way that is changeable?
What if you want to change all the /app pages to sit under /app_num1 ?
ROR have a helper methods for this ,call link method and ROR looks into
the routing tables and creates the reverse route for you.
I guess Dancer have/should have something similar.
I think it would be better for Apache::ASP to have a minimal routing .
Let say -
I wonder if Apache::ASP were to be made to work
with something like Plack, if it would pick up some routing potential on
the way (or maybe just a Plack way of doing things?)
I don't think so. I believe a minimum-effort Apache::ASP Plack port would
have only one feature relative to Apache::ASP v2, that being web stack
independence. From your perspective, the big difference is that you have
to replace all the mod_perl Apache2::Foo stuff with Plack/PSGI equivalents.
To get a handle on what routing does for Dancer, say:
$ sudo cpanm Dancer
$ dancer -a foo
This generates a complete, self-contained sample app, suitable for hacking
on directly. That is to say, the file and directory structure it generates
is suitable for production use.
The routing structure is in foo/lib/foo.pm. You also use this file to
define hooks, which are roughly equivalent to global.asa event handlers in
Apache::ASP. Script_OnStart is the same as Dancer's before hook, for
example. There is no direct equivalent of Session_OnStart, but you can
build that into the before hook, too. The Dancer equivalent to the
Application_* event handlers is foo/bin/app.pl.
If Apache::ASP were to get a routing system, I don't know that you'd
necessarily want to put it in global.asa. It works well for Dancer, but
perhaps another design would make more sense for Apache::ASP, since
global.asa has historical meaning.
Notice, by the way, that foo/lib gets added to @INC by foo/bin/app.pl.
This solves another problem I had with Apache::ASP, which doesn't like you
to define functions and classes in your *.asp files. You end up creating
*.pm files to hold all reused and complicated code. Where then do you put
those *.pm files so that mod_perl can find them?
In my Apache::ASP
Re: Migrate existing Apache::ASP code from mod_perl to mod_fcgid?
Sorry ,hit a send by mistake.
On Thu, May 22, 2014 at 10:55 PM, Warren Young war...@etr-usa.com wrote:
On 5/22/2014 11:01, Josh Chamas wrote:
You know I have not much followed the routing paradigms. To me it seems
that this would be an area I would have solved with a mod_rewrite or a
mod_perl handler, changing up the URL destination on the back end.
Routing is more than just an abstraction between the implementation level
and the presentation to the browser. It forces you to consider your
logical URL structure.
My Apache::ASP code just growed, like Topsy. One page at a time, with no
consideration of the interfaces exposed by the other pages. There was
consistency of design only to the extent that there was code copying, and
then in decreasing fashion with respect to time, as the cloned pages
diverged.
As soon as I started developing a system of routes in the Dancer port, I
realized that I had an API. It was sitting there the whole time, never
identified in the Apache::ASP form, but there it was in the Dancer code,
clear as day. Once I'd formally extracted it, I spent a day redesigning it
the way it should always have been. The correct design popped right out,
obvious as a green sky.
This happens because you have to describe your URL structure to Dancer,
one URL per line. Many fit in a single screen of text, so patterns jump
out at you.
Example in Dancer pseudocode:
get '/' = ...
get '/login' = ...
get '/logout' = ...
prefix '/app' = sub {
get 'page1' =
get 'page2' =
};
prefix '/api' = sub {
del 'foo/:id' = ...
get 'foo/:id' = ...
post 'foo' = ...
put 'foo' = ...
get 'bar/:id' = ...
...same as foo...
};
The story this route structure tells is clear:
1. First you go to the top level page, which perhaps has a Log In link or
button to send you to the /login page.
2. The /login page creates a session and bounces you to /app when you log
in successfully.
3. There's a button or link somewhere that sends you to /logout, which
destroys your session and sends you back to / or /login.
4. The app does CRUD-y things to foo and bar objects through
/api/{foo,bar}, creating via PUT, reading via GET, updating via POST, and
deleting via DELETE. GET and DELETE require a record ID to tell the
handler what to operate on, while PUT and POST must be fairly complex in
what they will accept, so that the parameters cannot be marked as required
in the route structure.
It's kind of like that Fred Brooks quote, Show me your flowcharts and
conceal your tables, and I shall continue to be mystified. Show me your
tables, and I won’t usually need your flowcharts; they’ll be obvious.
What you describe looks much like REST.
Is it good? I don't know .I guess it is a matter of taste .
Personally ,I like it sometimes and sometimes I wish it would just let me
do what I want and don't force to do the right thing.
The possible problem of this approach - you need a reverse routing API.
How do you link to an action in a way that is changeable?
What if you want to change all the /app pages to sit under /app_num1 ?
ROR have a helper methods for this ,call link method and ROR looks into
the routing tables and creates the reverse route for you.
I guess Dancer have/should have something similar.
But having all this in Apache::ASP could be an overkill.
I think it would be better for Apache::ASP to have a minimal routing .
Put your modules in app/lib directory
If you defined a route - look for the method in the module
If not just peek up and .asp file.
I wonder if Apache::ASP were to be made to work
with something like Plack, if it would pick up some routing potential on
the way (or maybe just a Plack way of doing things?)
I don't think so. I believe a minimum-effort Apache::ASP Plack port would
have only one feature relative to Apache::ASP v2, that being web stack
independence. From your perspective, the big difference is that you have
to replace all the mod_perl Apache2::Foo stuff with Plack/PSGI equivalents.
There are Middleware modules that maybe could be useful.
But having Apache::ASP have other options except mod_perl is a big deal.
To get a handle on what routing does for Dancer, say:
$ sudo cpanm Dancer
$ dancer -a foo
This generates a complete, self-contained sample app, suitable for hacking
on directly. That is to say, the file and directory structure it generates
is suitable for production use.
The routing structure is in foo/lib/foo.pm. You also use this file to
define hooks, which are roughly equivalent to global.asa event handlers in
Apache::ASP. Script_OnStart is the same as Dancer's before hook, for
example. There is no direct equivalent of Session_OnStart, but you can
build that into the before hook, too. The Dancer equivalent to the
Application_* event handlers is foo/bin/app.pl.
If Apache::ASP
Re: Migrate existing Apache::ASP code from mod_perl to mod_fcgid?
It has been a while.
Josh it is great you a here .
After Warren took the time to compare Dancer to Apache::ASP i had to look
into the framework.
Just read the Cookbook .
It seems like the Dancer is following the famous MVC/Ruby on Rails where it
can.
Routing,Layouts,DSL (OK ,Ruby is a DSL in a way by itself).
Apache::ASP is more like php in old days ,put a page and it will work.
I still think that Apache::ASP has it's place.Not just for legacy.
Putting a .asp file and have it work is an advantage.
It is a good idea to have a module/method be called with routing.
I know I miss it a lot for AJAX and data processing requests.
The most problem with Apache::ASP for by now is that it is tied to mod_perl
with it's module reloading ,memory hogging problems.
So I will be glad to invest some time in helping porting Apache::ASP and
introduce whatever is missing ,at least for me.
Evgeny
On Thu, May 22, 2014 at 2:52 AM, Josh Chamas j...@chamas.com wrote:
Thanks Warren for the write up! Sounds pretty exciting going full on into
a new framework and having that stick even better.
I built Apache::ASP back in the day when both PHP and Java were toys (even
Linux was half baked), and glue of the web and unix systems was often perl,
my first love of a language. Its all gotten a bit more evolved since then
to say the least. :)
thanks for hanging out these past years on the list!
Cheers,
Josh
On 5/21/14 4:42 PM, Warren Young wrote:
On 5/20/2014 13:06, Josh Chamas wrote:
So where does this put you in the consideration of platform migration
etc? Plack, Mason, TT, etc.
Shortly after I started this thread, I decided to just try one of the
alternatives, for education value if nothing else.
I narrowed my options to Dancer and Mason+Poet, as those are the only two
popular, full-featured, actively-developed Perl web frameworks that still
run
under Perl 5.8, which we're going to have to support for years yet.
Mojolicious
and Catalyst are the other main options, and they both require 5.10.
Mason is functionally quite similar to Apache::ASP, whereas I'd say less
than
50% of Dancer directly maps to the ASP way of doing things. Nevertheless,
I
decided to start with Dancer purely because it has a more active mailing
list.
I told myself that I would fall back to Mason if the Dancer experiment
fizzled.
As it turned out, Dancer delivered in spades, so I never did spend any
time with
Mason+Poet.
About the only things in Dancer that map 1:1 to Apache::ASP -- or near
enough
that simple regexes can fix up most of the differences -- are the Request,
Response and Session objects.
Dancer differs from Apache::ASP in pretty much every other way:
- There is no direct equivalent of Apache::ASP's Application and Server
objects. The features are all present in Dancer, but not collected
together in
the same way. For example, $Server-Config('foo') is config-{foo} in
Dancer.
(As a rule, Dancer function and object names are shorter than in
Apache::ASP.
For another example, $Request-QueryString('foo') is param 'foo' in
Dancer.)
- Dancer's API is a DSL rather than idiomatic Perl as in Apache::ASP. This
bothers to about the same extent that script blocks in an HTML file
bother
me. Bouncing between languages adds a context switch while reading code;
it's
worst when you have blocks of code that fill a screen, so that you have to
remember context of language A across a screenful of language B.
Apache::ASP can't throw stones, though, due to the mixing of Perl and
HTML in
*.asp files. It's easier to wrap the Dancer DSL in a Perlish API than it
is to
avoid Perl code in *.asp files.
- Apache::ASP's URL handing is file-based. That is, the mere existence of
$webroot/foo.asp means http://server/foo.asp is a legal URL. Dancer,
like many
newer frameworks, has a route-based URL system, meaning that you define
your
dynamic URL hierarchy in code, rather than in the filesystem. (Static
resource
files are still mapped directly to URLs in Dancer, of course.)
The files your route handlers use to fulfill each request is entirely up
to the
you. Some kind of straightforward 1:1 mapping (e.g. /foo/bar uses
views/foo/bar.tt) is sensible, but not by any means required.
- Dancer encourages you to separate your GET and POST handlers into
separate
routes, whereas with Apache::ASP, the path of least resistance is to put
them
both in the same file, for much the same reason that CGI scripts have GET
and
POST handling in the same file. You end up with stuff like:
if ($Request-{Method} eq 'POST') {
# Examine $Request-Form to figure out what kind of POST it is,
# extract data from the form data, process it, etc.
}
else {
# Do something entirely different for GET
}
# Render page, either a fresh one for the GET case, or a response to
# a form submission in the POST case.
Separating your POST and GET routes
Re: Problem with Apache::ASP under Apache 2.4
The sourceforge is more current if I remember correctly (I was trying to participate in the project a year ago but eventually was not able to, hope I will have a chance...) Anyway ,I guess that to make it work for multiple Apache version you should just check for function being declared (exists or defined would do that) Evgeny On Wed, Jul 10, 2013 at 10:41 PM, Koebrick, Andrew (MNIT) andrew.koebr...@state.mn.us wrote: Sorry for the misdirected reply. I have changed all reference from remote_ip to client_ip in the following Apache::ASP files on our system: Load.pm (1 occurrence) CGI.pm (2 occurrences) StateManager.pm (3 occurrences) That seems to have solved the problem. I hesitate however to post a patch since this fix is only good for Apache2.4 and I believe would break instances running on earlier version. Perhaps a wiser programmer can add the appropriate server version checks in a conditional so that it will work appropriately for all versions of Apache. Thanks again for the reply. Happy to see that people are still monitoring this list. Incidentally, what is the current project home? http://sourceforge.net/projects/apache-asp or http://www.apache-asp.org/? Andrew -Original Message- From: Warren Young [mailto:war...@etr-usa.com] Sent: Tuesday, July 09, 2013 6:15 PM To: Apache-ASP List Subject: Re: Problem with Apache::ASP under Apache 2.4 Please send replies to the mailing list, not direct to the one who replied to your post. On 7/9/2013 15:32, Koebrick, Andrew (MNIT) wrote: httpd-2.4 has changed it's API somewhat, the Apache2::Connection::remote_ip method is now Apache2::Connection::client_ip. So what happens if you change the reference on line 85 of Apache/ASP/StateManager.pm from remote_ip to client_ip? If it works, post a patch and someone with a commit bit will apply it for you. And, if there's anyone reading this from the Perl Apache API documentation team, why are the Apache 2.0 docs still the only ones on your site? - To unsubscribe, e-mail: asp-unsubscr...@perl.apache.org For additional commands, e-mail: asp-h...@perl.apache.org - To unsubscribe, e-mail: asp-unsubscr...@perl.apache.org For additional commands, e-mail: asp-h...@perl.apache.org
Re: and now for something completely different...
Great work! On Wed, Nov 21, 2012 at 2:22 PM, Thanos Chatziathanassiou tcha...@arx.grwrote: I shipped an apache-asp based project to a (new) client who was at a bit of a loss when reviewing the source. Since few people can really use vi the way it's meant, I had hacked around version 0.18 of geany's - well scintilla's - LexHTML to provide decent syntax highlighting for html+asp-perl+javascript. It is quite horrible in its innards since I just replaced most php stuff with perl and thus kept it for internal use thus far, but I'm providing a link here in case anyone's interested. http://public.arx.net/~thanos/**geany-0.18-asp-perl.tar.xzhttp://public.arx.net/~thanos/geany-0.18-asp-perl.tar.xz I am still half-way implementing it right in geany 1.22 and when that happens, I will send it in for merging with geany proper. Still, if you don't need php at all and you like geany, it's half-decent. Best Regards, Thanos Chatziathanassiou --**--**- To unsubscribe, e-mail: asp-unsubscribe@perl.apache.**orgasp-unsubscr...@perl.apache.org For additional commands, e-mail: asp-h...@perl.apache.org
Re: POST not working
I am not sure ,but it looks like BinaryRead will just read STDIN/mod_perl buffer entirely into internal buffer .While getting multipart/form-data a CGI object is used to read a file upload. This is just an explanation ,is that OK ?I guess yes. Evgeny On Tue, Feb 7, 2012 at 3:09 AM, Arnon Weinberg ar...@back2front.ca wrote: Thanks for this, ran into the same issue, and that fix worked perfectly. Note: This affects forms processed using CGI that are submitted with method=post and enctype=application/x-www-form-urlencoded (the default). Using method=get or enctype=multipart/form-data does not cause the problem, so may be another solution for some. - To unsubscribe, e-mail: asp-unsubscr...@perl.apache.org For additional commands, e-mail: asp-h...@perl.apache.org
Re: apache::asp maintenance ,again
Nice to hear that there are others interested as well ! I will be happy to provide any help needed . @Gregory I think public repository is probably better idea ,this way you will neither be a bottleneck .Other then that anything that you ,Thanos Josh prefer will be fine. I am personally is much more comfortable with svn then git ,but git have nice branch features . Seems like the module can live in Josh's directory on CPAN and this is great. Thanks Evgeny On Mon, Aug 15, 2011 at 3:23 AM, Gregory Youngblood g...@tcscs.com wrote: I tend to selfhost things but can put on sourceforge just as easily. I also prefer svn. I'd be glad to host it, as well as the SVN sample site if that would help. Just let me know. On Aug 14, 2011, at 5:18 PM, Josh Chamas wrote: On 8/14/2011 2:40 PM, Gregory Youngblood wrote: How about creating a patch and sending it to the list. For the short term it lets the fixes get out. Perhaps we'll hear from Josh or can make other arrangements. What do you think? Greg Thanos, Greg, I am happy to go into co-maintainer on this. I can look at patches or integrations when they come in for peer review, and can publish to web site still, which is simply built off of the perldoc from ASP.pm. Obviously not been highly engaged here, so great if others run with it! @Thanos, I think you had the biggest bundle of work that needed to get out there in terms of new db layer overhaul, so if you have any special considerations or interest here would love to hear it. Happy if some one hosts this in a reasonable open source repository, github, sourceforge type of gig. I guess I would be partial to something with svn offered and SourceForge seems to but no strong opinions here if it works and folks can collaborate, spin off trial forks, etc. Regards, Josh On Aug 14, 2011, at 11:09 AM, Thanos Chatziathanassiou wrote: I have numerous fixes for Apache::ASP including the one mentioned here. - To unsubscribe, e-mail: asp-unsubscr...@perl.apache.org For additional commands, e-mail: asp-h...@perl.apache.org
apache::asp maintenance ,again
Hi all. Yes ,we are still using the apache::asp ,it is a great peace of software after all. And we want to thank the original authors for the work they have done. Anyway ,it looks like there is not a lot of going on with the module now. Still, we are maintaining a very big application that uses it. We use perl + Apache::ASP extensively . I guess there are others out there in our position. Also, It looks like there is a need for at least one patch being applied . So ,maybe the original authors want to take the maintenance back? Or is there anybody with write permissions on the module in CPAN? We don't want any changes etc... just to make sure that everything works. Thanks Evgeny
Re: Content-Type header
Dear Rock the Kazbah and the list,
I was just hit by this problem when using ajax request with firefox .
(I know this mail is REALLY old )
Anyway ,for those guys ,like myself ,that are supporting ,applications
written with
apache::asp ,there are must be somebody that at least will have write
permissions
to the module on CPAN .
As an example this Content-Type bug from 2008 totally breaks ajax post
request from firefox.
There is a simple fix ,but we need somebody to apply it.
Thanks.
Evgeny
On Tue, Nov 25, 2008 at 8:31 PM, Rock the Kazbah momex2...@hotmail.comwrote:
Hi,
Back in June 2006, I asked about the content-type header as it relates to a
form post from a mobile phone browser. The original message that I sent can
be seen here:
http://mail-archives.apache.org/mod_mbox/perl-asp/200606.mbox/%3cbay113-f338ccae926acac394078a3bf...@phx.gbl%3E
In a nutshell, in most situations, the browser will send the content-type
header as 'application/x-www-form-urlencoded' but some browsers under
certain circumstances, add additional information at the end of the
content-type header string. In particular, Firefox 3 is sending
'application/x-www-form-urlencoded; charset=UTF-8' when a POST request is
initiated through AJAX. This causes the form elements being submitted in
AJAX to be ignored.
I manually did a change on the Apache::ASP::Request module to correct this
problem, changing the line
if($headers_in-get('Content-Type') eq
'application/x-www-form-urlencoded')
to
if($headers_in-get('Content-Type') =~
m|^application/x-www-form-urlencoded|) {
which solved the problem. However, as the change wasn't bundled into
Apache::ASP back then, I'm wondering if there's something else I should be
doing to solve this problem?
Thanks for any feedback.
.rw
--
Win a trip with your 3 best buddies. Enter
today.http://www.messengerbuddies.ca/?ocid=BUDDYOMATICENCA19
Re: Undefined subroutine error
Well you probably already thought of this but:
It appears that the global.asa (and thus Example::Image.pm) get
compiled into different
packages then templates/masthead.tmpl.
Do you have UniquePackages 0 or 1 ?
Maybe this is caused by a template package you are using ,is this an
asp script or another one?
If the problem actually _ is _ the different packages then you can of
cause solve it with
PerlRequire / startup script or something like that.
Thanks
Evgeny
On Tue, Nov 11, 2008 at 3:01 AM, Roberto C. Sánchez
[EMAIL PROTECTED] wrote:
MP gurus,
I recently deployed a site using Apache::ASP. I am running up against
a problem that has left me scratching my head. The site works fine on
the development server. However, on the production server, my error_log
fills with these messages:
[Mon Nov 10 19:44:59 2008] [error] [asp] [7796] [error] Undefined subroutine
Apache::ASP::Compiles::__ASP__srv_http_www_e_ample_com__x::get_image_data
called at /srv/http/www.example.com/templates/masthead.tmpl line 2. -- ,
/usr/share/perl5/Apache/ASP.pm line 1521
(I have attached the complete error log output, with debugging enabled,
for a failed request to this email.)
The odd thing is that it is apparently intermittent. Sometimes, the
error happens and a 500 error page is returned. Other times, the page
loads as expected.
Both servers (development and production) are running Debian Etch with
Apache 2.2.3, mod_perl 2.0.2, and Apache::ASP 2.59 (all stock versions
shipped with Debian Etch).
The code that is generating the error is this:
%
my %img_data = get_image_data('masthead.png');
%
My DocumentRoot is /srv/http/www.example.com and I have a directory
called /srv/http/www.example.com/Example which has my Perl modules in
it. One of the modules is called Image.pm and it has a function called
get_image_data(). In my global.asa I have use Example::Image;.
Something that also does not make sense to me is that if I change the
document root to something like /srv/http/example or /srv/http/site,
then the error appears to never happen. I have tested this by using
both alternate document roots for about two weeks each and it appears to
not have a problem in either case.
There are two very strange things about this whole situation. On the
(nearly) identically configured development server, I never get the
above error. I have another site (one that is actually in production,
as opposed to the example site) that uses a similar scheme on the same
production server and it does not have this problem.
Regards,
-Roberto
--
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFJGNlw5SXWIKfIlGQRAp2tAJ4hc3UfDt0LszN/6UTrRSErMtmnhACgv2j8
s4zfI5IlVrRykSFjU2X3gi0=
=O++Q
-END PGP SIGNATURE-
Re: saving decoded unicode value to Session causes error
Hi Richard!
First of all i need to apologize:
It is possible that i gave you a bad advice.
I am not a Apache::ASP developer, just a user that is monitoring the list
to follow the development (if any is making place ,i hope :) ) and
I have tried to help .As NOT a developer i hope it is allowed for me to
make
mistakes.
I will try to explain :
If you setup your server and/or application to send the header saying that
the
data is utf8 encoded then what you get from client will also be utf8
encoded.
That IS right .So,if you just use
$Request-Form()
to get the data posted you will get the utf8 encoded data and you probably
WILL be fine ,the same as i have said in the prev. reply.
However there IS a problem:
The string you will get from $Request object although utf8 encoded will NOT
be
marked as utf8 encoded .In other words - you get the data fine and if you
for example
store it in DBMS you are fine,but perl does not know that it is utf8
encoded.For
perl the data is just an array of bytes
Why does it matter for perl to mark strings as utf8?If you try to use
regular expr.
or some string functions (like length ,i think) it may not work because perl
will
assume to be character 8 bit long which not always true for utf8.
So ,my advise of just NOT using Encode::decode_utf8 may cause actually
problems
if you try to do some processing on the data you get.
Actually, i personally do exactly what i have advised to you :
Taking the data just like i get it from $Request and store it.
In the rare cases when i need to do some processing one the localized
data (like regular expressions match ) i am marking it as utf8.
Hmm, I thought that perhaps it was something with Apache::ASP, and
that SDBM_File would be a dependency that was being passed bad data?
I have made a test and it worked just fine,here is the code:
html
head
/head
body
form action= method=post
input type=text name=v
input type=submit
/form
/body
/html
%
use Encode;
my $v=Encode::decode_utf8($Request-Form('v'));
$Session-{v}=$v;
print $Session-{v};
%
I am also using SDBM_File .Thought i am obviously have another version of
perl :(
Why i think that this an SDBM issue?
The error you are getting :
Wide character in subroutine entry
means that you are trying to output/call function with wide utf8 character
while this file handler is not setup to get this kind of data .
A quick google search for MLDBM utf8 approves this. :(
So i guess you need a workaround or just try to use another DBM.
I suppose I misunderstood the purpose of this meta tag...so not
only output, but inputs get encoded as UTF-8 here? Cool stuff
Sometimes the meta tag get ignored and you need the header,also make sure
your
server does not send such a header by his own (Apache sometimes does).
When, then, would I need to use decode_utf8? I suppose it's for file-
reading or command-line input then?
If you need perl to know it is utf8 ,such as some of string manipulations.
Again,You may also try another DBM ,change your StateDB setting .
Maybe this is the best solution .
Evgeny.
Re: saving decoded unicode value to Session causes error
It looks like that SDBM_File file handler or something else in it's
internals does not
know that you are storing (writing) utf8 records into it.
I don't know how to force it to know this :( maybe some SDBM_File expert
here
will know.
However the workaround for this is to NOT mark the string you get as utf8
i.e.
don't do Encode::decode_utf8. Just set your pages/server to send to the
browser
header saying that you need utf8 as request charset and you will be fine.
meta http-equiv=Content-Type content=text/html; charset=utf-8
will do this or
$Response-AddHeader()
What this solution does NOT do - it does not validate the input to be legal
utf8.
But most of the time you will be fine.
Hope this helps.
Evgeny
**
On 8/29/07, Richard Yen [EMAIL PROTECTED] wrote:
Hi,
Wondering if anyone has ever encountered this issue.
Trying to internationalize my site, so at every input, I pass it
through Encode::decode_utf8.
However, when I attempt to put the values into Session, I get the
following message:
Errors Output
Wide character in subroutine entry at /usr/local/perl/lib/site_perl/
5.8.7/MLDBM/Sync/SDBM_File.pm line 80, GEN10 line 21. , /usr/
local/perl/lib/site_perl/5.8.7/Apache/ASP.pm line 1521
Debug Output
Use of uninitialized value in string ne at ../global/lib/
lib_filesystem.pm line 41.
Using an array as a reference is deprecated at ../global/lib/
lib_peer_review.pm line 389, line 21.
Wide character in subroutine entry at /usr/local/perl/lib/site_perl/
5.8.7/MLDBM/Sync/SDBM_File.pm line 80, line 21. , /usr/local/perl/
lib/site_perl/5.8.7/Apache/ASP.pm line 1521
An example is if I use the capital Omega character (option-z on mac
keyboard), this error occurs when attempting to store into Session:
my $secret_answer = Encode::decode_utf8($main::Request-Form
('secret_answer'));
$main::Session-{secret_answer} = $secret_answer;
I've discovered that if I put the decoded value into a hash, and then
put the hash into Session, it behaves normally. Also, if I don't
decode at all, it behaves normally also.
Would anyone know why this happens, or how to fix it?
Thanks!
--Richard
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: apache::asp maintenance
Those are great news! Thanks Josh. Evgeny On 6/25/07, Joshua Chamas [EMAIL PROTECTED] wrote: Tsirkin Evgeny wrote: On 6/19/07, *Warren Young* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On the other hand, I'm not aware of anything so badly wrong with it that we need someone to step in and take over. I think there are enough people using the library that it'd be valuable to see some new development, but I don't think the library is in danger of becoming irrelevant just yet. It still works, and it's still useful as it is. Good to know . Thanks. Thanks Warren. I plan to push another release in the next couple of weeks as the software does need updating, in particular for it to work well with the latest mod_perl 2 release. If you have other needs please let me know. Josh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: apache::asp maintenance
On 6/19/07, Warren Young [EMAIL PROTECTED] wrote: On the other hand, I'm not aware of anything so badly wrong with it that we need someone to step in and take over. I think there are enough people using the library that it'd be valuable to see some new development, but I don't think the library is in danger of becoming irrelevant just yet. It still works, and it's still useful as it is. Good to know . Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
apache::asp maintenance
Hi list! I was interested to know what is the apache::asp maintenance status? Is it still maintained?Is it dead? I have some applications here written in apache::asp and killing it ,for now ,is not an option.So,are there people, except me, that are interested in the module?Are there people out there using this and maintaining it? Evgeny
