Re: Apache::ASP Mod_perl
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 5/21/2014 17:52, Josh Chamas wrote: 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. One of my requirements was in fact that the next framework be Perl-based, and only partly because we had all this code already written. The other reason, of course, is that Perl remains a highly productive language for me. I still reach for it first when writing anything scripty, despite knowing a dozen or so other languages that could also accomplish the task. As Bjarne said[1], there are the languages everyone complains about, and the ones nobody uses. :) [1] http://www.stroustrup.com/bs_faq.html#really-say-that - 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 5/22/2014 00:45, Tsirkin Evgeny wrote: It seems like the Dancer is following the famous MVC/Ruby on Rails where it can. Dancer is actually a Perl reimplementation of a Ruby framework called Sinatra. (Get it? Dancer? Sinatra? Ahahaha.) Dancer is very much *not* MVC, only V. The problem with MVC systems is that they only work when you can write your M's and C's in the same framework, or connect directly to them. They also presume that there are M's and C's to be had in the first place. I suspect a lot of MVC apps out there are actually contorted designs, twisting themselves into the rigid MVC container. Apache::ASP and Dancer are both policy-free, in that they don't tell you how to design your app. They just give you a bag of tools and say, Go to it! For the sort of web app that doesn't fit well-established categories -- blogs, CRUD editors, etc. -- that's exactly what I want. Other examples are node.js, Nitrogen, Mason+Poet, and straight PHP. Counterexamples are Rails, Catalyst, Drupal, Zope... These all are more of a Framework-with-big-F. They are prescriptive, telling you, Build your app this way and it will be a lot easier. True only if your app speaks the framework's design language natively. - 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 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.
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 app, I ended up installing them into the system's
site_perl directory, and then I could never remember the path to those
files when I had to hand-hack one of these files on a production server
to test a problem fix in the field. With Dancer, the *.pm files are
right there next to the rest of the app.
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.
Yes, always been a problem, but memory is so cheap! :)
I know you're joking, but RAM on VPSes isn't
Re: Migrate existing Apache::ASP code from mod_perl to mod_fcgid?
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 reduces at least one indent level,
and keeps mostly-unrelated code separate. It also works better with
Ajax-based code, since GET usually returns HTML, whereas POST will more
likely return JSON.
- Dancer has built-in automatic data serializers for several common
formats: JSON, XML, YAML, Data::Dumper...
This is great for Ajax code since:
return {
foo = 'some value',
bar = ( 'a', 'set', 'of', 'other', 'values' ),
}
...serializes naturally to a JSON object. My Apache::ASP pages that
returned JSON had to manually set Content-Type and manually call
JSON::encode_json() to serialize my Perl objects for return from Ajax
handlers.
- Dancer offers many different templating systems, whereas Apache::ASP
offers just the one. Only one of the templating systems with a Dancer
adapter on CPAN -- Mason -- works anything like the ASP templating
language, in that it allows you to freely intermix HTML and Perl. I
initially tried using Dancer + Mason to minimize the amount of work
needed to translate my ASP code, but after running into some
difficulties I switched to Text::Xslate, and got hooked.
Systems like Xslate force you to collect all of the Perl code to build a
page into one location, and write the template as a separate file. This
makes both the Perl and template code clearer, since you're not visually
jumping back and forth between languages, as touched on above.
Template systems like this get you a lot of the benefits of the MVC
Migrate existing Apache::ASP code from mod_perl to mod_fcgid?
mod_perl no longer builds against Apache 2.4[1]. Consequently, the RHEL 7 beta doesn't include it[2]. The claimed replacement is mod_fcgid, but as far as I can tell from the Apache::ASP CGI page[3] the standalone CGI mode seems to require plain Perl scripts, not intermixed HTML + ASP/Perl files. So, does this effectively kill Apache::ASP? Is there another path forward, or should I be looking to migrate to some other framework? (Catalyst?) [1] http://www.apachelounge.com/viewtopic.php?p=25033 [2] http://goo.gl/Vn2Sxy [3] http://apache-asp.org/cgi.html - To unsubscribe, e-mail: asp-unsubscr...@perl.apache.org For additional commands, e-mail: asp-h...@perl.apache.org
Re: File upload problem / $Request-Form problem
Andrew Koebrick (ADM) wrote: asp title: cgi title: test title Would I be correct in guessing that this Apache::ASP application is brand new, and hasn't been running successfully for some time in the same configuration? If so, I would guess that you don't yet have Apache::ASP set up correctly. Try the examples, and the generic troubleshooting steps you can find in the mailling list archives and the docs. - To unsubscribe, e-mail: asp-unsubscr...@perl.apache.org For additional commands, e-mail: asp-h...@perl.apache.org
Re: File upload problem
Andrew Koebrick (ADM) wrote:
(http://www.apache-asp.org/cgi.html) that the recommendation is to roll
back to CGI v2.78.
The docs are just giving that version as a known-working example. I've
successfully uploaded files to servers running CGI.pm v2.89 and v3.15.
I end up with an empty file on my server.
Empty, or missing?
If you're expecting to access the actual file-on-disk, rather just read
the data via a file handle, you need to set
PerlSetVar FileUploadTemp 1
in your httpd.conf file. Otherwise, Apache deletes the temp file it
uses to hold the upload. As an example of why you'd care, my code sets
this configuration variable this because the first thing it does is 'mv'
the file to its new permanent home in the filesystem.
If I try to read directly from
request-Form I get the error:
Perl is case-sensitive, and the $ is not optional. It's
$Request-Form. I typically do this at the top of pages that receive
form posts:
if ($Request-{Method} eq 'POST') {
my $form = $Request-Form;
# process $form-{stuff} here
}
Being able to access the form values via $form saves a lot of typing.
my $filename = $query-param(Identifier-upload);
I would only use CGI.pm to set up the file upload form, as described in
the Apache::ASP docs. I wouldn't continue to use it on the POST
handling side like this. Apache::ASP has its own mechanisms, which I'd
trust more. Using the shorthand above, you'd say
my $filename = $form-{Identifier-upload};
instead.
my $upload_filehandle = $query-upload(Identifier-upload);
Again, you're fighting Apache::ASP by doing things through CGI.pm that
Apache::ASP already does. If you want just the file handle, that's
$Request-{FileUpload}{upload_field}-{FileHandle}
...in ASP-speak. See http://www.apache-asp.org/cgi.html#File%20Upload
If you set the httpd.conf variable as above, the name of the file is in
$Request-{FileUpload}{mfile}-{TempFile}
-
To unsubscribe, e-mail: asp-unsubscr...@perl.apache.org
For additional commands, e-mail: asp-h...@perl.apache.org
Re: newbie question
k0STEk wrote: Function HrF (Link, Alt, Group) Would you be surprised to learn that your newbie question is answered in the FAQ? http://apache-asp.org/faq.html#VBScript%20or%2007fa600d - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache::ASP Installation Issue
Randy wrote: In the browser, I get the asp script. That means Apache::ASP isn't even being called for the page, which is an Apache configuration problem, not a problem with Apache::ASP. (Problems with Apache::ASP or the ASP pages themselves show up as complaints in error_log.) In all of what you posted about your httpd.conf contents, I don't see that you've actually configured Apache to use Apache::ASP. This is from the top of the configuration section of the manual: PerlModule Apache::ASP Files ~ (\.asp) SetHandler perl-script PerlHandler Apache::ASP PerlSetVar Global . PerlSetVar StateDir /tmp/asp /Files I posted something much like it in my initial reply to you. It applies just as well on Windows as on Linux. Apache is Apache. I don't seem to have a global.asa file anywhere on the server. I don't know that Apache::ASP fails to work without it, but you do want it. Here's the default one: http://apache-asp.org/eg/global.asa Search for global.asa on apache-asp.org for more on what it does. Also see the documentation for the Global configuration option to see how to change where global.asa lives: http://apache-asp.org/config.html#Global In the snippet above, it appears it's telling Apache::ASP to look in the same directory as your .asp files, which may not be a good thing if you want the contents of your global.asa to be secret. You can use the Global directive to put global.asa outside the document tree, so Apache won't serve it. Alternately, you can configure Apache to never serve *.asa. Directory D:\Xxx\xx Are you sure this section actually works? From the Apache platform notes for Windows: because Apache uses Unix-style names internally, you must use forward slashes, not backslashes http://httpd.apache.org/docs/2.0/platform/windows.html What is the StateDir? Never heard of it. It's in the manual: http://apache-asp.org/config.html#StateDir By the httpd user to whom do you refer? The user that Apache runs under. It might not be your user account. If you run it as a Windows service, by default, it runs as the SYSTEM user. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache::ASP Installation Issue
Randy wrote: Any suggestions? (other than put it on a xxnix box) The common wisdom says that Windows is easier to use. In a lot of cases, this is true. This is not one of those cases. Apache::ASP is a native of *ix systems, and so it's far easier to install it there. You usually don't have to set up Apache, mod_perl, or compilers on a Linux box...they're just assumed to be there, already working, or at least easy to install. The lack of this support environment is what you're running into on Windows. Even if you have an absolute requirement to use Windows for the final product, I would suggest getting started with Linux first. That will give you necessary experience with Apache and Apache::ASP which will help you to understand the Windows instructions. You don't have to get dedicated hardware for this, or install Linux. You can download all this, ready to go. First, get VMware Player, here: http://www.vmware.com/download/player/download.html Now we need a VM. Download VA-LAMP-vmware-*.zip from: http://virtualappliances.net/download/vmware/ This VM is set up for basic Apache serving already. There are several more steps required to add Apache::ASP support, but all are easy. It might take 15 minutes, all told. 0. Install VMware Player. It wants to reboot the host machine, but it isn't really necessary. 1. Extract the contents of the VM zip file to the place you want the VM to live. You'll need 2.5 GB of disk space. 2. Open the VA-LAMP folder and double-click the VA-LAMP.vmx file you find inside. This will start the VM in VMware Player. 3. After the VM boots -- it won't take long! -- you'll see it report the IP address that your LAN's DHCP server assigned it. Write it down. For the sake of the discussion below, we'll say it's 192.168.0.42 4. Put that IP address into a web browser to test that the VM is working. You should see the VM's welcome page. 5. Say Start Run and put \\192.168.0.42\wwwroot into the Open field and hit Enter. This will connect to the directory holding the content being served from the VM by Apache. Log in as admin/admin when prompted. You should see index.html. Delete it, or move it off the VM. 6. Now we have to create the new Apache configuration file, and it's easier to do it in Windows and transfer it over, rather than transcribe it into the VM directly. You'll need a Unix-aware text editor for this. If you don't have one, I can recommend Notepad++, which is free: http://notepad-plus.sourceforge.net/ Paste the text below into a new text file, adjusting the first two lines as desired. If you're using Notepad++, say Format Convert to UNIX Format. Then save it out as \\192.168.0.42\wwwroot\asp.conf to write a copy of the new configuration file to the VM's virtual hard disk. -- 8 -- cut here - 8 - ServerAdmin [EMAIL PROTECTED] ServerName my-first-apache-asp-server DocumentRoot /var/www/html Directory /var/www/html Allow from all AllowOverride None DirectoryIndex index.asp Options FollowSymLinks Order allow,deny /Directory IfModule mod_perl.c PerlModule Apache::ASP Files ~ (\.asp) SetHandler perl-script PerlHandler Apache::ASP PerlSetVar Global /var/www/html PerlSetVar StateDir /tmp/asp /Files /IfModule -- 8 -- cut here - 8 - 7. Click back into the VMware Player window, log in as root/root, and give the following commands to set up Apache. First, we'll blow away the default Apache config and put our new one in its place: # cd /etc/apache2/sites-enabled # rm * # mv /var/www/html/asp.conf ../sites-available # ln -s ../sites-available/asp.conf . We've started with a minimal VM, so we don't have the C compilers and such on the system yet. Let's go get 'em: # apt-get update # apt-get install build-essential Now we need to set up CPAN: # cpan Answer the configuration questions, accepting all defaults. Now we can install Apache::ASP and its prerequisites: cpan install Bundle::Apache::ASP cpan exit Now, the clincher: we need to restart Apache, to load our new configuration: # apache2ctl restart This should run quickly and silently. It if complains, you did something incorrect above. 9. Pop out of the VM (Ctrl-Alt), open your Unix-aware text editor again, ensure it's in Unix line ending mode, and write this: % print Hello, world! % Save it out as \\192.168.0.42\wwwroot\index.asp and hit the refresh button in your web browser. The page should change to say Hello, world! If so, congratulations, Apache::ASP is working. Continue on with the examples at http://apache-asp.org/eg/ If all of this is too much for you to deal with, best just use Windows' own flavor of ASP.
Re: Peculiar problem with CompressGzip
Thanos Chatziathanassiou wrote: enable CompressGzip on that specific directory. What happens if you use mod_deflate instead? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache ASP question - RedHat Linux - Plesk8.2
hc_andy wrote: I've created a sample test.asp (code below) Where did you put it? What are the permissions on the file? What happens if you copy it to test.html and replace the Write() call with plain old static text? To get plesk/apache to display .asp pages, do I have to enable something somewhere Plesk being Plesk, it should just work once you've installed the module. If it doesn't, it can be a mess to find out why not, because Plesk likes to create alternate copies of configuration files in odd locations which it uses instead of the standard copy, which it leaves in place just to confuse you. The only solution to this is to stop using Plesk and go old school. (I am speaking as one who is strongly considering changing hosting providers for this very reason.) html body % $Response-Write(Hello, world!); % /body /html The syntax of your test file is fine. The problem lies elsewhere. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: apache::asp maintenance
Joshua Chamas wrote: I plan to push another release in the next couple of weeks Did you mean to type months? :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: apache::asp maintenance
Joshua Chamas wrote:
If you have other needs please let me know.
Well, for inertia reasons, we're still maintaining a lot of CentOS 3 and
Red Hat Linux 9 type systems, with mod_perls of 1.99_07 and _09 vintage,
which was before the big Apache2:: namespace reorg. As a result, when
installing Apache::ASP, I have to manually edit ApacheCommon.pm to
remove all the '2's. Also, the Apache2::ServerRec module doesn't exist
on these systems, so I have to comment it out. Apache::ASP then works
just fine.
It would be spiffy if the library detected this situation and coped
automatically.
I tested this, and it works here:
eval {
# Try new Apache2 module requests first
require Apache2::RequestRec;
require Apache2::RequestUtil;
require Apache2::RequestIO;
require Apache2::Response;
require APR::Table;
require APR::Pool;
require Apache2::Connection;
require Apache2::ServerUtil;
require Apache2::ServerRec;
require Apache2::SubRequest;
require Apache2::Log;
};
eval {
# Alternative if above fails because system is old, but not
# so old that it's incompatible.
require Apache::RequestRec;
require Apache::RequestUtil;
require Apache::RequestIO;
require Apache::Response;
require APR::Table;
require APR::Pool;
require Apache::Connection;
require Apache::ServerUtil;
require Apache::SubRequest;
require Apache::Log;
} if defined $@;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: apache-asp request querystring help
Spn wrote:
I have tried %=$Request-QueryString('MyEmail')% but it just write this to
the textbox, not the value.
Read the FAQ: http://apache-asp.org/faq.html#Examples%20donf48a0968
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: apache::asp maintenance
Tsirkin Evgeny wrote: 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? Well, on the one hand, the last update to the library was over two years ago, and the last post by its primary author was nearly a year and a half ago. 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ASP/VBscript
Jaime Iniesta :: RAILES.net wrote: Hi, I'm new on this list, my name is Jaime Iniesta and I live in Madrid, Spain. I wanted to know if Apache::ASP lets you parse ASP/VBscript files on Apache. I mean, will this page render on Apache::ASP? Do they not believe in reading FAQs in Spain? http://apache-asp.org/faq.html#VBScript%20or%2007fa600d - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache::ASP Access!
hinanaseeb wrote: i want to remove this facility from global settings and want to allocate it to only those hosts which request for it.How can i do that? The same way you'd make anything specific to just one virtual host: put it inside the VirtualHost block. If you want something stronger than that, for some reason, I suggest you start looking at virtualization. Neither of these subjects is on-topic here. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Global not always global?
D. L. Fox wrote: In .htaccess I have... This is the only thing that stands out for me. I wouldn't expect things like globals to work if you don't set up Apache::ASP in the main httpd.conf file, or some file it directly includes. Per-directory configuration should only be used for overrides, not global behavior. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache 2 CPAN installation
teufboy wrote: Syntax error on line 177 of /etc/apache2/httpd.conf: Invalid command 'PerlHandler', perhaps mis-spelled or defined by a module not included in the server configuration It looks like mod_perl is broken. Try: $ rpm --verify apache2-mod_perl If it prints anything, follow up on what it's reporting. It might be that there is some file corruption, or missing files. If it doesn't return anything, I'd check for an updated set of RPMs from your Linux distribution provider. Are these official RPMs, or something you downloaded from a third-party web site? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: asp host
D. L. Fox wrote: Does anyone have a list of web hosts that support Apache::ASP? You're narrowing your scope unnecessarily here. Unlike with the _other_ ASP, it isn't the case that Apache::ASP is either supported or it isn't. It would be nice if it were preinstalled and configured, but that isn't necessary. What you really must have are: 1) Apache; 2) permission to modify httpd.conf; 3) mod_perl; and 4) the ability to get arbitrary CPAN modules installed. There are a whole lot of web hosts that fit that criteria. There are a few web hosts that let you do all that without root access to the server, but I wouldn't recommend them. You often have to involve their tech support droids to get things set up, and that usually results in too much hassle, as you've found out. I imagine you're not in the market for a dedicated server. Therefore, I would recommend any of the VPS sort of web hosts: ones that give you root access to a virtual machine so you can run CPAN yourself. I've just been through this myself, so I can give you a few tips in selecting a provider: 1. Be sure to check versions of everything. I briefly tried setting up Apache::ASP at one hosting provider that was still using Red Hat Linux 7.3! You probably have no idea how hard it is to get modern software to build on something that old. Since new software is freely available, the Linux world tends to abandon backwards compatibility much more quickly than the commercial software world. You want to find a host where the major pieces aren't more than a few years old. You don't need to be bleeding edge, just avoid the overly conservatives ones. 2. A lot of cheap hosting providers keep their prices down by putting some pretty severe restrictions on the amount of RAM given to each customer. 64 MB is just not enough. Even if you strip down MySQL and Apache to turn off all the space-for-time tradeoffs they have -- child prespawning in Apache, big caches in MySQL, etc. -- you'll still be running up against memory limits. You might actually get it working, but you won't be able to run things like system updates while the web and database servers are up. Start a second Perl interpreter instance, or a C++ compiler, or a tool like yum, and you're running the system out of memory again. Apache::ASP does Bad Things (TM) when it runs out of RAM. I'd say 96-128 MB is the smallest reasonable amount. 256 MB is plenty, ignoring application-specific overhead. 3. As for how to find such hosts, a Google search for Linux VPS will turn up dozens. There are a few companies using OSes other than Linux, and some don't call it a VPS, but you'll get plenty of choices. Just some names to demonstrate the variety out there: VPSLink, Linode, Web Intellects, and Verio. Between those four, you can probably find a 10:1 price ratio, a 5:1 base resource ratio, not a single control panel that's the same among them, wholly different management models Look at those four, then look at another dozen before making your decision. There's a company out there with exactly the right feature balance for you. There's too much competition for two companies to offer exactly the same service set. We've got hyper-differentiation going on here. bothered to contact me four or five times with a We're still working on it! type message. It took them less seconds to charge my credit card than it has days to get my account setup. Naturally. Charging your credit card is a solved technical problem. One should not rely on someone else's tech support droids to solve technical problems. I hereby posit the theory of the 4 Rs of Tech Support: Reboot, Reinstall, Replace, or Refuse to Acknowledge. If your problem requires another solution, you're better off doing it yourself. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: libapache-asp-perl
Marcelo Iepsen da Silva wrote: I use the module libapache-asp-perl in debian stable version. But I can't read asp files, have another configuration in httpd.conf or other file? Go to http://apache-asp.org/ and read the manual. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Installation Errors
levik wrote: When I browse to the folder(located in my webroot) in IE I get HTTP 500 - Internal server error. Look in Apache's error_log, then. Post the entire error text if you don't understand it. It could be many lines. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Installation Errors
levik wrote: I did post my error log, didn't I? Sorry, I missed it. Here's the start of the relevant line: [Wed Jul 19 08:46:07 2006] [error] [client 127.0.0.1] can't open file /tmp/asp/server/internal.lock: No such file or directory at It's looking for /tmp/asp/... This isn't going to exist on a Windows box! Change the line in httpd.conf referring to this to some temp space Apache can use. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cleanly separating applications vs. presentation using Apache::ASP
Steve B wrote: The most notable design flaw is the tight integration between the application and the display. Perl code is directly intermingled with the HTML page, making the external management of the page elements nearly impossible. You're right, there is a lot of religion on this topic. The way I see it, you can't be pure either way. You will always end up with some UI code in your application logic, or vice versa. And I don't advocate trying to separate them as much as possible. That leads to holy quests, where what is being tested is your purity by the standards of the particular priest you're following, not the soundness of your design. What I do is look for reusable code, and blocks of closely related code, and put that into Perl modules. The reusable code bit is obvious: no sense duplicating code, right? But I'll also collect together many related functions and put them into a class, and make that a Perl module. Most of these functions might be called from only one .asp file, so it's not a matter of reuse, but it is fair to say that all of these functions logically function together, so they should be kept together. This makes the most sense when these functions don't have any reason to contain any HTML. For instance, I have a layer between the database and the UI code in my current project, and the code forming that layer is in a single large .pm file. They return raw data (hash references, arrays, etc.), which the ASP code then renders into a human-usable format. The ASP code that calls these functions is a mixture of Perl and HTML: it might call a function in the module that returns an array of hash references, and use that to build an HTML table containing the data. That mixes some Perl code with my UI code, but that's fine. What matters is that the meat of the application code is separate from the UI code. Another rule I have is that .asp files should contain mainly HTML. Code sections in other languages -- Perl, JavaScript, etc. -- should never be longer than will fit in your programmer's editor window. You should be able to see some HTML in the editor window at all times, because that helps you to keep your mind focused on the context of the application. When you're skipping over great swaths of foreign code to see how one HTML section works with another, you cannot see this flow. I like to keep these sections of code shorter than 10 lines, if I can. These snippets of code should be there just to glue pieces together, not to contain serious blocks of logic. This isn't to say that I'll interrupt a block of, say, 30 lines of Perl code to spit out one pure line of HTML, just to divide that block and satisfy my previous rule. In that case, I'll often put the HTML into a Perl print statement, just to keep the flow of the Perl code going. Again, it's about maintaining flow...don't confuse the code's reader by switching between languages more than necessary. You satisfy all of these rules at once by minimizing the amount of Perl code that needs HTML interspersed, and the amount of HTML that needs Perl in it. I guess what I'm saying is, separation of UI and application code is a high-level rule that you do not follow directly. You follow many lower level rules that together create this effect, giving the illusion that you're following just this one high-level rule. You have to think in terms of the low-level rules, because it turns into a matter of heuristics: you'll have two or more options, neither of which is wholly right or wrong, and you'll have to make some kind of choice between them. Making that choice by following the high-level generalized rule can lead you into a mess, whereas weighing the many low-level rules against each other can make correct the path clear. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: UTF-8 HOWTO
Joshua Chamas wrote: Do you know why it is that use utf8 is needed at the top of each script? No, I'm not sure. At this point, I just know that there are pages where, if I remove the pragma, the UTF-8 characters get munged. I haven't tried to localize the Perl constructs in which this happens. What precisely were the problems that you were running into without this setting? The most common symptom was what looked like double UTF-8 encodings. That is, Unicode characters that should have encoded as 2 bytes in UTF-8 were showing up as 4 bytes. I didn't try to reverse the double conversion to make sure this is what was happening, but I can't think of a more likely explanation for the symptom. The opportunity here is that we could automatically add something like this to the top of each page. I'll consider investigating deeper. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
UTF-8 HOWTO
I finally got around to converting our Apache::ASP application so that it uses UTF-8 throughout, instead of Latin-1. I learned a few things that aren't discussed in the archives, so I'm setting them down here for others to find. 1. It's best if you use newer Perls. 5.8.0 is adequate, but has known bugs in its Unicode handling. When run under 5.8.0, our program exhibits a double UTF-8 conversion in one circumstance, while the other screens show the data correctly. When the same program is run under 5.8.5, all screens show the correct data. While it's theoretically possible to get Perl 5.6.x to cope with UTF-8 data, I don't recommend messing with it. A few years ago when I first tried using UTF-8, I was using 5.6 and had many problems with Perl smashing my data back to Latin-1 incorrectly. 2. Also use the newest mod_perl you can. There are known Unicode bugs in mod_perl 1.99_09 and older. 3. You must say use utf8; at the top of each ASP file. If you use $Response-Include(), each included file also has to say use utf8;. The same goes for any Perl modules you use, if you will be passing UTF-8 strings through them. 4. mod_perl doesn't set the LANG environment variable unless you ask it to. Perls 5.8 and newer use the LANG environment variable (among other things) to decide whether to use UTF-8 by default or not. I didn't find it to be necessary to ask mod_perl to set this variable in my program, but it can't hurt to do it. If nothing else, it's one less thing you have to blame if your pages aren't showing the right data. In your httpd.conf, right after PerlModule Apache::ASP, say PerlPassEnv LANG. This will pass your system's default value for LANG through to the mod_perl instances, and thus to Apache::ASP. 5. Ensure that your data source is passing UTF-8 data correctly. In our program, the data comes in via an XML path, so we needed to inform the XML parser that the data is UTF-8. Otherwise, the XML parser assumes it's Latin-1, and you get a double UTF-8 conversion. 6. Finally, you need to communicate that the data is UTF-8 to the browser. This is done with the Content-Type HTTP header, which you can set in a number of ways. I like to do it in a meta tag at the top of each file that will contain UTF-8 data: meta http-equiv=Content-Type content=text/html; charset=utf-8 Alternately, if all documents on your server should be treated as UTF-8, there's an Apache configuration directive to force all output to be declared as UTF-8. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Install problem
Andrew Koebrick wrote: [error] Can't locate Apache2/RequestRec.pm in @INC [snip] mod_perl-1.99_16-3 The current version of Apache::ASP assumes that you are using the new mod_perl 2.0 interfaces. 1.99_16 uses the old mod_perl 1.0 interfaces. One option is to upgrade mod_perl. The dependency net that package is caught in makes this a messy path. The way I choose is to edit the file referenced in that error message (ApacheCommon.pm), changing all the Apache2s to Apache. Then try starting httpd. It will fail again, telling you one more module that it cannot find; edit the file again, and remove the line that references it. httpd will start now. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: migrating asp, .net application from IIS to apache
nsm100 wrote: I have an application done using ASP, .NET using IIS Web server. The customer wants to migrate the application to Apache server. Whats the best option which involves less time in migrating to the Apache ? ChiliSoft or some other such commercial thing, if your time is not free. Apache::ASP uses an entirely different programming language (Perl, not VB), though the programming model is the same. This is covered in the documentation on apache-asp.org. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: APACHE::ASP Error
sangeethvs wrote: suggestions of installing BerkeleyDB. But isn't that overkill. Do we really need to install the DB_File and BerkleyDB modules to work with Apache::ASP? There are alternate state storage models, but BDB is certainly a good choice. I seem to recall that one of the options is a native Perl module (i.e. no C code, as in BDB) but that would be slower. Bottom line, you definitely need some database layer to store the ASP state data. What's wrong with installing BDB? It's been around since before Linux became the biggest *ix, so it probably builds out of the box on your Solaris system. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with PDF files
Jonathan Dixon wrote: Files ~ (\.pdf) SetHandler perl-script PerlHandler Apache::ASP PerlSetVar Global /storage/t212 PerlSetVar StateDir /tmp/asp PerlSetVar RequestBinaryRead On /Files This declares *.pdf files as being ASP files. Apache::ASP is trying to interpret them directly! What you want to do cannot be accomplished with this mechanism. Try looking at the various Apache modules. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Arguments truncated semi-randomly
Joshua Chamas wrote: This is an Apache/mod_perl API, Ah, that was the clue I needed. From the mod_perl changelog, just one release past the one we are using: fix $r-read to read all the requested amount of data if possible, adjust the test TestApache::read to verify that [Stas] I haven't tried it yet, but I'm confident this will squish the bug. Thank you, Josh! Your wisdom and patience are an inspiration. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Arguments truncated semi-randomly
We have an ASP application which mostly works, but on one particular
form, POSTed updates are randomly ignored. I think we have the problem
isolated, but we're stuck for another reason. I'll take you through the
debug process so you know what the situation is so far.
- The symptom is that when $Request-{Method} eq 'POST', our code goes
through the hash referred to by $Request-Form looking to see what kind
of 'POST' it has received. In the failure case, we find that no form
elements at all are present in the referred-to hash. This is plainly
why the update is being ignored. The question is, why are there no
arguments in the hash?
- We tried sniffing HTTP packets to see if there was a difference
between the success and failure cases. Viewed as a stream, there is no
difference: the arguments are definitely going down the wire. Here's
the start of a typical HTTP POST request:
POST /bla.asp HTTP/1.0
Host: bla
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5)
Gecko/20041217
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://bla/bla.asp
Cookie: session-id=03fab6464ed0a18ba861190243a9de9f
Content-Type: application/x-www-form-urlencoded
Content-Length: 2343
channel=28r113_z10=on
I made it a quotation so my mailer wouldn't wrap lines. Some names
changed to protect the innocent. :) The elipsis at the end indicates
many other arguments. This particular ASP page shows something on the
order of 1200 check boxes in a grid, and there is one rXXX_zXX
argument for each checked box.
- I set ASP's debug level to -1 and diffed the logs between the success
and failure cases. The only significant change is this one:
Success: read 2343 bytes, tried 2343 bytes
Failure: read 1387 bytes, tried 2354 bytes
That message is printed by ASP/Request.pm, line 232. This is plainly
the culprit: the read() call above this line isn't returning the entire
HTTP request in a single call.
The main reason I'm posting to the list is because it isn't clear to me
what the cleanest way to fix this is. I could hack some loop on that
read() call, but I'd rather Josh chimed in on this one.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cross-over between sessions
Patrick Conroy wrote: (my $histtype, my $dsc, my $contactid, my $usrid, my $dbh) = @_; You want my ($histtype, $dsc, $contactid, $usrid, $dbh) = @_; here. my $sth = $dbh-prepare($sql_inserthistory) or die Couldn't prepare statement: . $dbh-errstr; For efficiency reasons, you should prepare that statement just once, and reuse it. Possibly make it a global variable and init it in one of the OnStart event handlers. But, I wind up getting a lot of history records from one user written with the usrid of another user in a different session. I don't see anywhere that you're using the $SessionID. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: UTF8 - Who is wrong? Apache::ASP or mod_perl or Apache or Perl?
k_berov wrote: Hi Boys. I think it's perl's fault, but if someone of you had such problems and tell mi what is wrong, I will be very gratefull. If you search the archives for a post I made less than a year back, you will find that I documented some interesting conversion chains in my application. You might find it helpful to read through it. The core of the problem is that Perl does not run in UTF-8 mode by default. It either tries to guess that it should use UTF-8 (e.g. the LANG environment variable) or it is told that it should use UTF-8 by directive. So for instance, the Apache::ASP Perl interpreter could be seeing a different environment than other Perl code on your system because of the way mod_perl works, and so it will convert incoming UTF-8 to Latin-1. Then if your httpd is configured to use UTF-8, it may try to convert Latin-1 back to UTF-8. The thing to do is to carefully find all of the stages in your system by tracing data through the system. Once you find all the transition points, you will know which code needs to be changed to enforce a pure UTF-8 data path. It is interesting that Perl 5.6.1 does not make such problems That's because Perl 5.6 made fewer attempts to convert data. 5.8 is more clever, which can be a problem as well as a benefit. There should be no reason for this disaster to happen to me. Sure there's a reason. It's called Murphy's Law. Cope with it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache::ASP locking up
Christopher Hicks wrote: You might be tripping over a bug in the db code. A bug in which db code? If it's part of the open source underpinnings of Apache::ASP, why is the bug still there? Why haven't you submitted a patch? Can you try the Apache::ASP on a Fedora Core 2 or 3 machine? We have no evidence that correlates the problem with platform. Before we send a person out to a remote site to do an OS upgrade, we'd have to have a pretty good idea that it will fix the problem. try this out on a nonproduction box.) Since we don't know how the box is being locked up, how could we test whether the OS upgrade helped? Again, we have many, many other sites...surely if it was as simple as an OS issue, some of our other RH7.3 systems would also be locking up. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache::ASP locking up
Josh Chamas wrote: What is the state of the system when it locks up? These systems are installed in schools, so they're only being used from roughly 7am to 4pm. This problem is happening within that window, while it is being used during the day. We have never seen it lock up in this way over night. Is the machine under load To the extent that 5500 hits per day is load, yes. :) There seems to be a loose correlation between the problem and load: this site is one of the heaviest users. We have heavier users, though, that aren't seeing the problem. is a process spinning out of control, We don't notice a busied out CPU, if that's what you mean. And, I wouldn't think anything is truly deadlocked, since all it takes is removing the ASP state directory to fix the problem. is there any errors in the error_log that look interesting? No, but then we send a lot of stuff to error_log ourselves. And, we don't have Debug turned up. Should we? Does restarting the web server help things without removing the /tmp/asp entirely, No. or is removing that directory the only fix? Yes. If the details you provided about /tmp/asp are before removing but after a freeze, then I would say there is nothing that looks out of the ordinary there that would raise concern on my side. Hmmm... Would having the files help? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Apache::ASP locking up
We have a site where Apache::ASP appears to be locking up every few days. If we rm -r /tmp/asp, the system begins responding again. We've upgraded to the latest Apache::ASP, and it doesn't help. The system is a Red Hat Linux 7.3 machine running Apache 1.3.27-4. None of our many other sites are having this problem, to the best of our knowledge. (They're not under our direct control.) On the other hand, we have an incredible diversity in our installed systems. So, there's no telling whether the problem is the machine's software configuration, or it's part of the environment the machine is being used in, or it's the users. Here's what 'ls -lR /tmp/asp' says: [EMAIL PROTECTED] root]# ls -lR /tmp/asp /tmp/asp: total 48 drwxr-x---2 apache apache 4096 Nov 18 05:03 00/ drwxr-x---2 apache apache 4096 Nov 18 08:55 01/ drwxr-x---2 apache apache 4096 Nov 18 09:31 02/ drwxr-x---2 apache apache 4096 Nov 17 15:48 03/ drwxr-x---2 apache apache 4096 Nov 18 09:24 04/ drwxr-x---2 apache apache 4096 Nov 18 09:16 05/ drwxr-x---2 apache apache 4096 Nov 18 09:24 06/ drwxr-x---2 apache apache 4096 Nov 18 09:26 09/ drwxr-x---2 apache apache 4096 Nov 18 09:16 0c/ drwxr-x---2 apache apache 4096 Nov 18 09:16 0e/ drwxr-x---2 apache apache 4096 Nov 18 08:51 0f/ drwxr-x---2 apache apache 4096 Nov 18 08:51 server/ /tmp/asp/00: total 0 /tmp/asp/01: total 0 /tmp/asp/02: total 16 -rw-r-1 apache apache 0 Nov 18 09:31 0245e15d91fa6bc24f45455ebb1b118c.dir -rw-rw-rw-1 apache apache 0 Nov 18 09:31 0245e15d91fa6bc24f45455ebb1b118c.lock -rw-r-1 apache apache 8192 Nov 18 09:31 0245e15d91fa6bc24f45455ebb1b118c.pag -rw-r-1 apache apache 0 Nov 18 09:25 02cc91f1cd27bbe3dcd8d2da1bfd5c6f.dir -rw-rw-rw-1 apache apache 0 Nov 18 09:35 02cc91f1cd27bbe3dcd8d2da1bfd5c6f.lock -rw-r-1 apache apache 8192 Nov 18 09:35 02cc91f1cd27bbe3dcd8d2da1bfd5c6f.pag /tmp/asp/03: total 0 /tmp/asp/04: total 0 /tmp/asp/05: total 0 /tmp/asp/06: total 0 /tmp/asp/09: total 0 /tmp/asp/0c: total 16 -rw-r-1 apache apache 0 Nov 18 09:01 0cafb734b4fee71793b02eac8e49682c.dir -rw-rw-rw-1 apache apache 0 Nov 18 09:34 0cafb734b4fee71793b02eac8e49682c.lock -rw-r-1 apache apache 8192 Nov 18 09:34 0cafb734b4fee71793b02eac8e49682c.pag -rw-r-1 apache apache 0 Nov 18 09:16 0cdaf20928718a3c45b05a8a6fdf8d70.dir -rw-rw-rw-1 apache apache 0 Nov 18 09:16 0cdaf20928718a3c45b05a8a6fdf8d70.lock -rw-r-1 apache apache 8192 Nov 18 09:16 0cdaf20928718a3c45b05a8a6fdf8d70.pag /tmp/asp/0e: total 0 /tmp/asp/0f: total 0 /tmp/asp/server: total 16 -rw-r-1 apache apache 0 Nov 18 08:51 application.dir -rw-r--r--1 apache apache 0 Nov 18 09:35 application.lock -rw-r-1 apache apache 8192 Nov 18 09:35 application.pag -rw-r-1 apache apache 0 Nov 17 15:05 internal.dir -rw-r--r--1 apache apache 0 Nov 18 11:38 internal.lock -rw-r-1 apache apache 8192 Nov 18 09:35 internal.pag The only thing that looks out of place to me is that the *.pag files here are larger than some others I looked at. This site gets an average of a about 5500 hits per day. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: file upload status bar (a la yahoo attachment status bar)
V.I. wrote: Please, tell me would be my best options to display the upload status as the files are being uploaded We ended up writing a Windows uploader that worked outside the HTTP stream. This works in our situation because we have tight control of the clients, we are uploading huge files that could cause problems with the CGI upload method anyway, and we have a custom server program running alongside Apache anyway. Another option we looked at are any of several Java-based upload mechanisms. These work, but none of them was better than our custom uploader for our purposes. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Help!
Mike Cantone wrote: might be using up a lot of memory, Stop guessing and measure! Does your platform have a top command? You can use that to see CPU time and memory usage. If not, you may have sar or some other system load testing utility. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: View contents of loaded global.asa
Nicholas Schuetz wrote: Does anyone know how I can view the contents of the global.asa loaded durring runtime. That would be chasing the symptom, not the cause. Instead, convince yourself directly that the global.asa you think is running is in fact being compiled. Add something like this to Script_OnStart: print STDERR Oooga booga\n; When I reference check_db_connection () from one of my asp files I get an undefined sub routine error. You could say this instead of the above for more info: print STDERR Oooga booga , ref \check_db_connection, \n; It should say Oooga booga CODE. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Large file upload problems
Josh Chamas wrote: you might consider using the mod_perl interface directly for the file uploads, by first disabling Apache::ASP's file upload processing: What is the benefit from doing this? And then using the Apache::Request interface to get the $apr-upload data. I tried to install Apache::Request, but it complains that it doesn't work with mod_perl2 yet. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Large file upload problems
Ian Cass wrote: I guess you could play with this... http://search.cpan.org/~tels/bignum-0.15/lib/bigint.pm ... and see if you can get CGI.pm using it. Wouldn't you know it, but Lincoln Stein proposed something similar when I reported the problem to him. He says he'll be making that section of the code use Math::BigInt, which appears to be a related module. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Large file upload problems
Stuart Johnston wrote:
Try setting this at the top of your script:
$TempFile::TMPDIRECTORY='/target/location';
What is $TempFile? Do you mean something under $Request-{FileUpload}?
Perhaps $Request-{FileUpload}{file}-{TempFile}?
There is a mod_perl module you might find helpful:
http://search.cpan.org/search?query=UploadMetermode=module
Hmmm...too many server configuration requirements. I need to do this on
multiple servers that are already set up.
Also, we use a java applet for upload which give a progress meter as
well as some other features:
http://jupload.biz/
Interesting, but its focus on multiple file uploads makes it suboptimal
for our simple needs.
Sorry, I don't have any suggestions on your other question.
That third one is the killer. If I can't get past the 2GB limit, it
doesn't matter how easy or efficient the solution is.
I think what I'm going to do is step outside HTTP/ASP altogether. I've
got this hammer, so all my problems are looking like nails. HTTP is
primarily a file download protocol; I'm swimming against the stream to
use this protocol for uploads. I think I'll write a native program that
will use a more appropriate protocol to upload the file. This won't be
onerous for our purposes.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Large file upload problems
I have an ASP page that needs to accept files which are typically rather
large. (Average 2GB +/- 1GB.) These files ultimately need to be stored
in a particular place in the web server's file system. I've set it up
so that the temp file is kept around, so that I can simply do a
system(mv $tempfile $target) within the ASP code to move the uploaded
file into place.
That works, but there are a number of weaknesses I've run into:
1. Since $tempfile is on the system disk and $target is on a big RAID
array, the move incurs a lot of extra disk I/O. Is there a way to tell
CGI.pm or Apache::ASP to use a directory on the RAID array instead of
/usr/tmp?
2. There seems to be no upload progress indicator, at least with
Mozilla. Is there a way that I can insert some code that gets run right
after the first HTTP header on the upload gets processed, so I can pick
off the expected file size? If so, I could pop up a window with my own
progress bar.
3. Something in the chain is barfing if the file is too large. The
limit seems to be just under 2GB. Here's the spewage I get in the log
for a 1.99GB file:
[Fri Apr 30 20:47:31 2004] [error] [client 172.16.0.42] Malformed
multipart
POST!!MultipartBuffer::read('MultipartBuffer=HASH(0x8b214ac)',0)
called at (eval 109) line
55!!MultipartBuffer::new('MultipartBuffer','CGI=HASH(0x8ba6b58)','---9040894219264',-2147483254,'undef')
called at (eval 107) line
4!!CGI::new_MultipartBuffer('CGI=HASH(0x8ba6b58)','---9040894219264',-2147483254,'undef')
called at (eval 106) line
3!!CGI::read_multipart('CGI=HASH(0x8ba6b58)','---9040894219264',-2147483254)
called at /usr/lib/perl5/5.8.0/CGI.pm line
415!!CGI::init('CGI=HASH(0x8ba6b58)','undef') called at
/usr/lib/perl5/5.8.0/CGI.pm line 286!!CGI::new('CGI') called at
/usr/lib/perl5/site_perl/5.8.0/Apache/ASP/Request.pm line
81!!Apache::ASP::Request::new('Apache::ASP=HASH(0x824ce84)') called
at /usr/lib/perl5/site_perl/5.8.0/Apache/ASP.pm line
387!!Apache::ASP::new('Apache::ASP','Apache::RequestRec=SCALAR(0x8b41f64)','/home/tangent/mms5/cli/mma-edit-title.asp')
called at /usr/lib/perl5/site_perl/5.8.0/Apache/ASP.pm line
181!!Apache::ASP::handler('Apache::RequestRec=SCALAR(0x8b41f64)')
called at -e line 0!!eval {...} called at -e line 0!, referer:
http://frank/mma-edit-title.asp?tid=97sid=1
I'd guess some bit of code along the path is treating the Content-Length
header as a signed 32-bit value. This is a Linux 2.4 system, so it can
handle large files. What code is to blame here?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Undefined subroutine
Søren Tauber Lassen wrote: files.pl: Rename it to files.pm, and put it in the same directory as your global.asa. Say use files at the top of global.asa. Restart the web server. sub loadFileText Within files.pm, say require Exporter; and read the documentation on the Exporter module to find out how to use it to export loadFileText into the global namespace. menus.pl: This should probably be another Perl module, not a *.pl file. require ../../cgi-bin/soren/files.pl; If you need routines from files.pm here, you shouldn't need a require or use statement here if menus.pm is loaded from another module that does load in files.pm. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Perl editor
John Drago wrote: Just out of curiosity, what editor do you folks normally use when writing perl? vim with syntax highlighting enabled. What editor do you used when writing perl inside HTML in ASP-style? Ditto, with these additions to my .vimrc file: function SetupASP() exe set syntax=aspperl call SetTS(2) endfunction au BufEnter *.html call SetTS(2) au BufEnter *.asp call SetupASP() au BufEnter *.inc call SetupASP() au BufLeave *.html call SetTS(4) au BufLeave *.asp call SetTS(4) au BufLeave *.inc call SetTS(4) The tabstop changes aren't essential. I just like less indenting with HTML, because it gets so deeply nested, especially with embedded ASP code. Have you heard of the OptiPerl Visual IDE? I have been using it for some time and really like it. But it isn't vi! It isn't an editor if it isn't vi. :) Of course, when I'm just logged in over SSH I use pico when I can (never quite got the vi commands down). Time you learned... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: UTF-8 problems ....
Josh Chamas wrote: PerlSetEnv LANG $LANG Does this resolve the UTF8 issues? It probably will. I really like it that you can keep the same LANG variable as the system uses. I wouldn't like to have hard-coded it. Right now, the stable version of my program has worked around this issue simply by building in understanding of where the conversions between UTF-8 and ISO 8859 occur. In my development version, I had intended to try for keeping data UTF-8 through the entire pipeline, so I will try this. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Application_OnStart not getting called
Josh Chamas wrote: This is a good point, and was the basis for the original implementation, that the application starts when the first visitor registers a session. This was the definition of the original Application_OnStart event in the ASP model. That's reasonable. If I understand things correctly, the real need is to calculate something once per application, More accurately, the new event would be for calculating something when the web server first comes up. I was able to actually use the current Application_OnStart in my situation once I understood how it actually behaved. The consequence is simply that I have to nuke the StateDir every time I change Application_OnStart's implementation, to force that event to be re-run. If I were still working on the code, this would be a fair annoyance. The difference with new event is that it would run every time the parent web server comes up, regardless of whether the application is considered to be restarting. Restarting the web server to make new changes appear isn't a problem at all. I have to do it often already, since much of my code is in Perl modules, which don't get reloaded when they change. Global_OnStart or Global_OnCompile ( Global_OnStart seems consistent ) Global_OnStart is good. which would be executed when the global.asa is compiled for the first time. If one wanted this to occur just once per server start, then running Loader() to get it compiled there would be the trick, otherwise it would be executed just once per httpd process. I was thinking Global_OnStart would be in lieu of getting Loader working. Once you get Loader working, code at the end of global.asa has this once on Apache startup behavior, doesn't it? The only gray area would be if you changed global.asa. It gets recompiled in this case. Would Global_OnStart be re-run? I suppose it could work either way. It may be that necessarily Global_OnStart would have to occur before $Application or $Session is set up ( effectively before Application_OnStart or Session_OnStart ) effectively. Would this event still be useful if this is the case? Yes, that's still useful. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Application_OnStart not getting called
Josh Chamas wrote: Currently, Application_OnStart only runs when the first Session gets initialized, and again after the last Session expires. Theoretically, this could never happen if your application is always busy. A big difference between Apache::ASP, and IIS/ASP is that sessions persist by default beyond the web server stop/start by writing to StateDir. Aha! That's the ticket. If I nuke my StateDir, Application_OnStart() is called right when the first session is created. The requests for this have been sporadic, and it has never been one of my top priorities, should it be? If the current behavior is useful for others, then it might be nice to have a new event that has the behavior I expected. No rush, this is mostly a syntax issue. (Reasoning below.) The top priority is simply to document the actual behavior of Application_OnStart. The current docs are misleading. If the current behavior is of no use to anyone, then Application_OnStart should be modified to behave the way the docs currently imply. Aparently this will increase logical compatibility with IIS/ASP, generally a good thing. If it will take a long time to get around to doing this feature, the current behavior should be documented, possibly with a link to this thread in the mail archives for workarounds. instead of calculating once per server start, it will be calculated once per web process initialization of global.asa. ... if you are using script preloading with Loader(), then you will actually get this calculation done during the parent web process init, On reading the first quote, my question was, How is code in Script_OnStart() different from code at the end of global.asa? I suspect the second quote hints at the answer: code at the end of global.asa runs only once if compiled in the parent httpd, whereas Script_OnStart() always runs once per httpd child creation regardless of whether global.asa is already compiled when the child starts. Yes? And if so, there is no difference between them when global.asa must be re-compiled for every httpd child, excepting order of events. I had Loader() working on my stock RH7.2 systems, but it broke in RH9 for reasons I haven't bothered to chase down yet. I'll try re-enabling it later. If it works, it's a fix for my problem. The syntax is wanting compared to Application_OnStart, but I can live with that. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Automatic recurring events (think cron for ASP)
John Drago wrote: d) Use a cron job to execute code that sends an http request to an ASP page on the server? (Even though this works great, it seems wrong somehow). This is the right way. All the cron job has to do kick off the event: */5 * * * * wget -O /dev/null http://localhost/dosomething.asp All the code to actually dosomething is on the ASP side, hence you have access to all the ASP variables. The main problem with this method is that you may need to hide dosomething.asp in an .htpasswd protected directory so outsiders can't call it. Use wget's --http-user and --http-passwd flags to call the protected script. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Application_OnStart not getting called
I have some code I'd like to run just once when Apache::ASP comes up the first time; it computes a value that never changes over the life of the application. For some reason, this event never seems to be called. I dug into the Apache::ASP code a bit, and the only thing that struck me is how deeply buried the call to Application_OnStart seems to be. Perhaps one of the many conditions wrapping this call is faulty? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Semi OT: UTF-8 handling
It seems that the UTF-8 support in Perl is still transitional. By that I mean that there are situations where you can find strings being converted back and forth between UTF-8 and the local character set (Latin-1 in my case) several times as it passes through the system. Here's a chain I've observed on one of my machines: DB - daemon - HTTP - ASP - Browser Latin-1 UTF-8 Latin-1 UTF-8 (View with a fixed-space font.) DB is a special-purpose database we use; there's some Latin-1 encoded data in it. daemon is a background process written in Perl that sits between the special database and the Apache::ASP code. When it pulls the data in from the database, Perl upconverts the data to UTF-8 on systems like Red Hat Linux 9 where the LANG variable is set to something like en_US.UTF-8. The daemon uses HTTP::Daemon to interface with the ASP code. We do it this way for reasons that aren't germane to the discussion. What's important is that in the ASP code, the LANG variable is unset for whatever reason. Therefore, Perl seems to convert the UTF-8 encoded data back into Latin-1, probably within the HTTP parsing code. It's clear, at least, that it's in Latin-1 throughout the ASP processing. The data finally seems to be converted back to UTF-8 by Apache before sending it off to the browser. Presumably this is because modern browsers advertise UTF-8 support. Right now, we're coping okay with these conversions. The only concern is that the conversion from UTF-8 back to Latin-1 is unnecessary. Some day, we wight decide to go in and force things to maintain the data in UTF-8 all the way through the chain beyond that first conversion, for efficiency. Does anyone know how we can force Perl to keep the data in UTF-8 format, even when the LANG variable isn't set? Incidentally, we see a different conversion chain on Red Hat 7.2, which uses Perl 5.6.1 and Apache 1.3. The data seems to stay in Latin-1 until sometime within the ASP code, where it's converted to UTF-8. Very strange, but since the last conversion is the only one that matters to our code, it works out for the best in our case. Just FYI, for the mail archive diggers. :) Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The Freakiest thing...
Josh Chamas wrote: Better yet, if you have common subs that you want to share between scripts, put them into the global.asa file, ...or put them into a Perl module, which you can place in the same directory with the global.asa file. Import the library with a 'use' statement at the top of global.asa. We have an Apache::ASP application with dozens of subroutines, all stored in pm files. The only code in the ASP files are the bits completely unique to that page's function. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: Internal server error when viewing sample asp scripts
Uwe Riehm wrote: Maybe for the time being a quick and dirty hack could be a solution to this: just search / match in the input file for some of the most used keywords of VBScript and in case one of those is found stop all the processing and output such an error message. A refinement on the idea: only do the check if the Perl interpreter fails. It would just be a best guess as to why the interpreter died, rather than being a proactive nanny-bot second-guessing your code with a low-end parser. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: Internal server error when viewing sample asp scripts
Josh Chamas wrote: However, I disagree with the premise that this will help the end user confusion. Most initial posts on this subject are with an internal server error resulting, as the developer has not yet set Debug 2 or 3 which are the settings which will result in a verbose HTML message going to the browser. So we still need to ask what is in the error_log. Perhaps the suggested Apache config in the getting started docs should set Debug to 3. I know I personally started out just copy-pasting from the docs when setting up Apache::ASP. I didn't start changing things until I gained a few clues, and that didn't happen until after my code started generating sane pages. I wouldn't have minded verbose errors in the browser when I was a newbie, since they can be turned off later. I wouldn't even discuss the debug option in the getting started docs. Just leave its meaning for newbies to discover later, when they're ready to start taking the reins into their own hands. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Script preload fails on RH9 setup
Josh Chamas wrote: I believe the mod_perl 2 on RedHat 9 is a pretty early dev release. True. They shipped the _07 release, which dates back to September of last year. Try upgrade to the latest mod_perl 1.99_xx. I know that decent Perl section support was only added more recently. I just installed the _09 release from source, and the problem persists. I haven't rebuilt Apache from source. That's still stock. Perhaps I need an Apache::compat directive in there somewhere? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Script preload fails on RH9 setup
Warren Young wrote: Syntax error on line 1059 of /etc/httpd/conf/httpd.conf: I should mention that line 1059 is the /Perl line. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Script preload fails on RH9 setup
Josh Chamas wrote: In your perl section, you could try, no strict qw(subs); No dice. This seems like a bug on Apache::PerlSection, and you might report it to the mod_perl list if you get this to work. That was enough of a clue to fix it. I pounded out the use strict at the top of PerlSection.pm and everything's working beautifully. Naturally this is not a final solution, but it will suffice for my immediate purposes. I will go ahead and post about the bug to the mod_perl list. Thanks again, you two. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mainframe Question
crazyday55109 wrote: 7.0 and Apache 2.x. I am trying to find a way to run ASP's on it but I have been working with Sun and they cannot run in a VM atmosphere. The ChiliSoft software will only run in an Intel environment. This implies that you already have these ASP pages, and that the script parts are written in VB. Apache::ASP uses Perl for the scripting, so you'd have to rewrite that code to use Apache::ASP. If the code isn't too complex or voluminous, this rewrite may not be much more than a straightforward mechanical exercise to someone who understands both languages. If there's a lot of it or if it's hairy code, you'll probably be best off looking into one of the VB-based solutions. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
