inheritance and Apache::Request
I am slowly learning about OO from Tom's tutorial, and was able to do inheritance with
two dummy classes I wrote, including adding methods to the subclass and have them work
too. However, when I tried to inherit from Apache::Request, it doesn't seem to work
right. Maybe this isn't an Apache::Request issue, so forgive me if that's the case,
but here's what I got:
FooBar.pm
-
package FooBar;
use strict;
use Apache::Request();
@FooBar::ISA = qw(Apache::Request);
sub fooey {
print hello world, I'm in FooBar;
}
-
Handler.pm
-
sub handler {
my $r = shift;
$r-send_http_header('text/html');
my $form = FooBar-new($r);
$form-fooey;
$r-exit(OK);
}
Here's the error I get:
[Thu Feb 14 12:35:14 2002] [error] Can't locate object method fooey via package
Apache::Request (perhaps you forgot to load Apache::Request?) at
/path/modified/Handler.pm line 21.
RE: inheritance and Apache::Request
Ok, that makes sense. But the reason I didn't include a new method for FooBar was because I don't know what A::R's new method does, so I didn't want to override it. What if it does some init stuff to the object? I'm assuming that's what's happening because, after adding a new method to FooBar, when I try to call $foobar-param (which I have not overridden), the child process segfaults. Oh well, I guess at this point I need to go back to reading more on perl OO since it's not sinking. Thanks for your help! --Alex -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] The problem is that package FooBar doesn't have a new method. Here's what happened as a result. When you called 'FooBar-new($r), perl looked for a sub called new in package FooBar. Since it didn't find one, it looked at FooBar's @ISA, and looked in Apache::Request for a new method. There it presumably found one, so that statement didn't return an error. But, the new() in Apache::Request probably returned an Apache::Request object instead of a FooBar object, so when you called $form-fooey, it only looked in Apache::Request and any modules in it's @ISA. You might want to look at using the universal isa and can methods while you're debugging and trying stuff out. Good luck! Wes Sheldahl
[OT] Re: New mod_perl Logo
On Wed, 30 Jan 2002, Ron Savage wrote: All these American-style names are verging on the racist. People should instead take into consideration the alternative suggestions you provided...oh wait, nevermind. --Alex
is there something wrong with my http header?
I'm trying to print a gif image to the browser, but it's appearing as
text. Here's what the output looks like (used lynx --mime_header):
HTTP/1.1 200 OK
Date: Mon, 28 Jan 2002 21:58:05 GMT
Server: Apache/1.3.20 (Unix) mod_perl/1.26
Set-Cookie: FOO=bar; domain=foo.bar; path=/
Pragma: no-cache
Cache-control: no-cache
Connection: close
Content-Type: image/gif
Expires: Mon, 28 Jan 2002 21:58:05 GMT
R0lGODdhOAAWAPcAVQAAqgAA/wAkAAAkVQAkqgAk/wBJAABJVQBJqgBJ/wBtAABt
VQBt
...(more data)...
My script does the following:
$r-no_cache( 1 );
$r-content_type('image/gif');
$r-send_http_header;
$r-print( $data );
$r-exit(OK);
Any thoughts?
TIA,
--Alex
RE: is there something wrong with my http header?
I'm a goof. That data is from an imap server--I forgot to decode it first. Thanks, --Alex -Original Message- From: Robert Landrum [mailto:[EMAIL PROTECTED]] Sent: Monday, January 28, 2002 4:16 PM To: [EMAIL PROTECTED] Subject: Re: is there something wrong with my http header? I'm trying to print a gif image to the browser, but it's appearing as text. Here's what the output looks like (used lynx --mime_header): HTTP/1.1 200 OK Date: Mon, 28 Jan 2002 21:58:05 GMT Server: Apache/1.3.20 (Unix) mod_perl/1.26 Set-Cookie: FOO=bar; domain=foo.bar; path=/ Pragma: no-cache Cache-control: no-cache Connection: close Content-Type: image/gif Expires: Mon, 28 Jan 2002 21:58:05 GMT R0lGODdhOAAWAPcAVQAAqgAA/wAkAAAkVQAkqgAk/wBJAABJVQBJq gBJ/wBtAABt VQBt ...(more data)... Uhh... That's not gif data. gif data should start GIF89a...(more data)... Rob -- When I used a Mac, they laughed because I had no command prompt. When I used Linux, they laughed because I had no GUI.
RE: Can't call Apache::Request-new()
Paul, I have version .33 working on perl 5.6.1 on a redhat 7.2 box (I compiled perl myself). However, if I do the command you do below, I get the same error. --Alex -Original Message- From: Paul Makepeace [mailto:[EMAIL PROTECTED]] Sent: Friday, December 14, 2001 12:43 AM To: [EMAIL PROTECTED] Subject: Re: Can't call Apache::Request-new() So no replies to this -- could someone even confirm they have a working Apache::Request v0.33 on perl 5.6.1? That would be a big help in at least determining whether it's perhaps something amiss here. Else I'll file it as a bug. Cheers, Paul On Tue, Dec 11, 2001 at 09:11:50PM -0800, Paul Makepeace wrote: I'm getting the following error, $ perl -MApache::Request -e 'Apache::Request-new' Can't locate object method new via package Apache::Request (perhaps you forgot to load Apache::Request?) at -e line 1. $ ...both from the command line and under a PerlHandler Apache::Registry'd script. Of course, it is installed: $ perl -MApache::Request -le 'print grep /Request/, values %INC; print $Apache::Request::VERSION' /usr/local/lib/perl/5.6.1/Apache/Request.pm 0.33 $ In all other respects I'm able to discern so far mod_perl, Perl and Apache are working here (I have a number of sites using Template Toolkit with a custom PerlHandler and a few scripts under Apache::Registry). I'm getting this error from both a fresh CPAN install and Debian's libapache-request-perl package (not installed at the same time!). Any suggestions where to start looking? Thanks, Paul PS Rather than cluttering your inbox, perl -V is at http://paulm.com/tmp/perl_v.txt
[OT] RE: Programmer Wanted
Actually, the funny thing about that job is that you don't make much money writing code, but by hiring other mode_perl programmers to work for you. --Alex -Original Message- From: Joe Breeden Sent: Friday, October 12, 2001 3:56 PM To: [EMAIL PROTECTED] Subject: RE: Programmer Wanted Sounds like morning talk radio to me. 'And now Ernie the Eye in the Sky with traffic, but first YOU to can be RICH. With our patented money making scheme the money literally prints itself.' --Joe Breeden --- If it compiles - Ship It! -Original Message- From: Robert Landrum [mailto:[EMAIL PROTECTED]] Sent: Friday, October 12, 2001 3:50 PM To: BuildReferrals.com; [EMAIL PROTECTED] Subject: Re: Programmer Wanted At 10:43 AM -0700 10/12/01, BuildReferrals.com wrote: Hello, My name is James Ventrillo, the webmaster of BuildReferrals.com and CompanionBar.com. I am looking for a programmer to be part of my company. We have a staff of 8 and we desperately need an additional programmer. Over the next few weeks, we need extensive programming performed on our websites. We will pay an hourly rate, dependent on your experience. Is it just me, or do all these multi-level-marketers sound the same? Whether they're writing spam or job postings, it still comes out sounding cheezy... Rob -- Only two things are infinite: The universe, and human stupidity. And I'm not sure about the former. --Albert Einstein
RE: [OT] New Micro$oft vulnerability?
Adi Fairbank wrote: I wish someone would just write a worm that would put these IIS machines out of their misery and stop causing the rest of us such a headache. I think that it would be a lot easier to write a worm that puts IIS admins out of their misery--they're already busy applying dozens of incremental patches as it is. Only a few more worms are needed before disgruntled admins call it quits. =)
Apache::MP3 error
My setup: - redhat 7.1 - perl 5.6.0 (original redhat rpm) - mod_perl 1.26 (compiled) - apache 1.3.20 (compiled) I installed Apache::MP3 per the instructions in the docs. perl.conf: VirtualHost 192.168.123.100 ServerName removed ServerAdmin removed DefaultType text/plain DirectoryIndex index.html Location /songs PerlSetVar CacheDir/usr/tmp/mp3_cache SetHandler perl-script PerlHandler Apache::MP3 /Location /VirtualHost httpd.conf: # for Apache::MP3 AddType audio/mpeg mp3 MP3 AddType audio/playlist m3u M3U startup.pl: use MP3::Info; use Apache::MP3; use CGI; I put a single MP3 in the 'songs' directory. In what appears to be the first request each child gets, the page pulls up fine. However, any subsequent requests to each child result in this error in the error_log: [Thu Sep 6 00:51:23 2001] [error] Can't call method start_html on an undefined value at /usr/lib/perl5/5.6.0/CGI.pm line 258. Any ideas? --Alex
Re: [OT] Inspired by closing comments from the UBB thread.
Jay Jacobs wrote: I don't see any glue-sniffing symptoms from choosing embedded html in perl over embedded perl in html. Unless, of course, you're the graphic artist and you've been tasked with changing the look and feel of the application using embedded perl (which you, as the graphics person, probably don't know anything about), while the perl developer works on the perl portions of the code, then you might be sniffing some glue. This the motivation for some (if not most) of the templating solutions Perrin mentioned. --Alex
Re: remove me
Hmm, if we could do that, it would be like Survivor. The tribe could get members removed off the list. =) --Alex Gordon Stewart wrote: hi Can someone please remove me. Thanks Gordon
Re: CGI module or Apache
There's Apache::Request, which is the equivalent of CGI.pm in the areas of form submissions and Apache::Cookie for cookie handling. If you're not using the HTML rendering capabilities of CGI.pm, you may look into those two. --Alex Kevin Schroeder wrote: Hello, I've been using the CGI PERL module for a while now and I like using it a lot. But I was wondering if using that module with mod_perl will slow things down because of the extra module being used. If so, is there a way to use the Apache API and mod_perl to deal with form submissions, cookies and the like? You'll have to forgive me, I've been learning mod_perl off of the cheat sheet at refcards.com. Kevin Schroeder
RE: Apache::Session / No-Cookie-Tracking
One easy way to find out if the original site uses cookies is by using lynx with the mime_header argument: lynx -mime_header http://e-commerce-site-in-question/foo/bar | less This will print out the HTTP headers before the content, like show below: HTTP/1.1 200 OK Date: Fri, 25 May 2001 18:04:32 GMT Server: Apache/1.3.12 (Unix) Expires: Thu, 24 May 2001 18:04:33 GMT Pragma: no-cache Set-Cookie: FOO=BAR; domain=e-commerce-site-in-question; path=/cgi-bin Connection: close Content-Type: text/html HTML HEAD ---snip--- If that Set-Cookie header is there, the script uses cookies. The -mime_header argument may vary by version of lynx (i think). Check the man page if the syntax above doesn't work. Alternatively, you can telnet to port 80 of the website and do a GET /path/to/script. Just make sure you have lots of scrollback if the page has lots of content. =P P.S. I'm pretty sure Explorer 5.x does NOT store session cookies on disk, but other browsers may. --Alex -Original Message- From: Joe Breeden Sent: Friday, May 25, 2001 12:55 PM To: '[EMAIL PROTECTED]' Subject: RE: Apache::Session / No-Cookie-Tracking Seems like the site in question is using either a hidden form element or a session cookie. I'm guessing that with the session being only valid as long as the browser window is open a session cookie is being used. The reason you don't see this in the Cookie directory for you particular browser is that these cookies are stored in the memory - they are not to be save after the browser session is over. I hope that helps. Joe Breeden -- Sent from my Outlook 2000 Wired Deskheld (www.microsoft.com) -Original Message- From: Jonathan Hilgeman [mailto:[EMAIL PROTECTED]] Sent: Friday, May 25, 2001 11:29 AM To: '[EMAIL PROTECTED]' Subject: FW: Apache::Session / No-Cookie-Tracking Sure - I believe in magic, depending on your definition of it. I KNOW there's a 4th method, because I've seen it work. There is an e-commerce web site which uses an outside cart programmed in CGI (Perl?). The original web site passes no identifying marks such as the session ID through the URL or through the form's submit button to add an item to the cart. I know, because I designed and created the web site. However, when the visitors hit the submit button, they are taken to another program/website containing their shopping basket filled with their items. I have figured out that it relies somewhat on the IP address, but not completely, because I have tested it behind the firewall and the other computer behind the firewall with me does not share the same basket. Once I am at that screen (viewing the contents of my cart on the program), there are other links which contain a session ID of sorts carried via the URL. The thing that is driving my head crazy is how they identify the user in the first place to create the links with the session ID. I accidentally caught them during testing or something and got a variable on the URL line. (I substituted the domain name - it's not really cart.com) http://www.cart.com/cgi-bin/cart.cgi?cartidnum=208.144.33.190T 990806951R5848 E cartidnum seems to be: $IP-Address + T + Unix-TimeStamp + R + Unknown number + E By the way, the session only seems to active until the browser completely shuts down. Any ideas? If I could identify my users on another site without using cookies at all, that would be fantastic! Jonathan -Original Message- From: Ilya Martynov [mailto:[EMAIL PROTECTED]] Sent: Friday, May 25, 2001 9:02 AM To: Jonathan Hilgeman Cc: '[EMAIL PROTECTED]' Subject: Re: Apache::Session / No-Cookie-Tracking JH I want to be able to track visitors without the use of cookies. JH I don't want to rely on IP address, because people behind proxies and JH firewalls seem to have the same IP address. JH I don't want to rely on a session ID variable being always present in the JH URL, in case the window gets closed or changed. JH Now, two questions: JH 1) Will Apache::Session provide an environment variable like JH HTTP_USER_AGENT that will contain an identifier that will always JH be consistent for that specific user, despite proxies and JH firewalls, and despite the changing/closing of windows? JH 2) If not, does anyone know of a good way to do this? Do you believe in magic? :) The only way to track visitors is either: 1) use cookies 2) use session ID variable in URI and/or hidden field with session ID in forms 3) use IPs (which is bad because it is completely broken approach) 4) use HTTP authorization (which is not always convenient because requires user registration) Apache::Session can only create persistent storage of session data. Each session data identified by some session ID. This ID should be taken from somewhere (see above). --
RE: Concepts of Unique Tracking
Although I agree about privacy issues, I will keep it short by stating that there is a difference between identifying you as unique user 1309850825 (assuming no personally identifiable information is also collected) versus identifying you as Stephen Adkins. You can use the first method to collect aggregate information about what percentage of your users are accessing what parts of your website the most/least, so you could customize your website appropriately. That does not require me to know who everyone is, personally speaking. --Alex -Original Message- From: Stephen Adkins [mailto:[EMAIL PROTECTED]] Sent: Friday, May 25, 2001 1:14 PM To: Jonathan Hilgeman; '[EMAIL PROTECTED]' Subject: RE: Concepts of Unique Tracking How quickly we forget ... Don't we remember the huge outcry over Intel putting a unique ID in every CPU which would could be transmitted via web browser and destroy all of our privacy? The frustration we feel as programmers who are trying to identify anonymous visitors is exactly what privacy is all about. And I am thankful for it. Get used to it. People need to opt-in in order to be identified. The closest thing we can get to this is people leaving their cookies enabled on their browser. Stephen At 10:43 AM 5/25/2001 -0700, Jonathan Hilgeman wrote: Let's take over the world and recompile all browsers to have them send out the MAC address of thet network card. Jonathan
