Re: Apache::Session
On Mon, 2002-03-25 at 15:44, Stathy G. Touloumis wrote: > Has anyone ran into issues with data being written to the data source using > Apache::Session::Store::DB_File and Apache::Session::Lock::File? We are > running into a unique instance where a value is not being saved to the > session store at a certain point through a workflow. There are multiple > frames which are making requests but only one frame makes the request to the > server which runs code to write to the Session store. We do have > KeepAlive's enabled so I don't think there should be any contention issues > when attempting to write to the store. Nevertheless this still seems like > the only reason this might be happening. > > Apache 1.3.22 > mod_perl 1.26 > Apache::Session 1.54 Could you give a little more detail please? Lots of people have lots of problems with Apache::Session, but it always comes down to not destroying Session objects. -jwb
Re: 0 being appended to non mod_perl scripts.
On Thu, 2002-03-21 at 08:37, Mike Wille wrote: > Hello all, > > I apologize if this has already been answered elsewhere, I haven't been able > to find it. > > I am encountering a wierd problem where perl scripts running under a normal > cgi-bin (ie no mod_perl) have a '0' appended to the output. This does not > happen to scripts run under mod_perl. It also only happens when > PerlSendHeader is set to on. I thought that PerlSendHeader was a mod_perl > only directive, but just to check I added PerlSendHeader off to the cgi-bin > directory. That had no effect. > > Has anyone else encountered this and how did you fix it? Are you sure this isn't an artifact of chunked encoding? Perhaps your browser or Apache are handling the encoding badly. I suggest you use a tool such as ethereal to examine the data on the wire. -jwb
Re: [ANNOUNCE] mod_perl logo
On Mon, 2002-03-04 at 08:26, Jonathan M. Hollin wrote: > Friends, > > The time has now come to cast your vote(s) for the new mod_perl logo (to > accompany the new mod_perl website which is now almost complete). You > can select your preferred logo at > http://www.tohubohu.net/cgi/mpchallenge.; You can vote for a new logo, > or button or both. You can also vote to keep the existing logo/button. > If a new logo is chosen, then a banner (or banners) will be designed > around the chosen logo. Didn't we do this a couple years back? I thought this time camels and feathers were discouraged ...
Re: Apache::Session
On Sun, 2002-02-24 at 02:43, Christoph Lange wrote:
> Hi Milo,
>
> thanks for your answer. I hope you will excuse, but I am not sure
> whether I got you right.
> > The session hash is serialized/deserialized in its entirety using the
> > Storable module.
> Does this mean, that - after tying the session hash - it is of no importance
> (concerning the amount of time needed) whether I do
> %everything_from_session_hash = %session_hash; # or
> $everything_from_session_hash{element1} = $session_hash{element1};
It is of no importance.
-jwb
Re: "Streaming" compression of output from mod_perl handler?
On Tue, 2002-02-19 at 06:11, Igor Sysoev wrote: > On Tue, 19 Feb 2002, [iso-8859-1] Nicholas Oxhøj wrote: > > > > if mod_deflate will receive flush request it will flush > > > deflate encoding > > > and will write compressed content to Apache buffer. But it does not > > > flush Apache. Anyway the max block is 8K, Apache buffer is 4K and OS > > > usually should send data if in OS's buffer there is more then 2K. > > > So it's probably MSIE feature as well as NC4 can not render tables > > > until it receive ''. > > > > If it was a "bug" in MSIE, it must be something specifically related to receiving >compressed content, since the same data sent uncompressed, gets rendered as they >arrive. > > > > Anyway, I just tried getting the same data using lynx, and this made it evident >that *without* mod_deflate, the data gets sent by Apache as they are ready, whereas >*with* mod_deflate, all the compressed data are sent as one big block at the end. > > I'm not sure that lynx can handle compressed response on the fly - > it uses gzip in pipe. > The best way to test it using netcat. > > > So it seems that I am still unable to get the functionality I am looking for. > > I you like to test I can make patch for mod_deflate to flush Apache. > But if major browsers can not handle compressed content on the fly > it's not valueable. I did some experiments using Ethereal to capture the IP stream between my browser and rambler.ru. On an example request, the timing was: 0.000 Initiate connection 0.245 Acknowledge connection 0.245 Request sent 0.530 Response receieved 0.540 Response continued 0.823 Response continued 0.826 Response finished It is difficult to tell from these timings whether the response was sent in steps or not. A useful test script would do something like for 50 times: sleep one second; print 1KB; -jwb
Re: mod_perl, mod_gzip, incredible suckage
On Thu, 2002-02-14 at 15:07, Stephen Clouse wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Thu, Feb 14, 2002 at 02:44:53PM -0800, Jeffrey W. Baker wrote: > > Hrmm how interesting. My Apache is built with PHP (with DOM, MySQL, and > > Postgres) and mod_perl. With mod_gzip enabled it simply segfaults on > > every single request. > > We have (other than the standard modules) mod_perl, mod_php, mod_ssl, mod_gzip, > mod_rewrite, and mod_auth_db, all statically linked. (At one point mod_fastcgi > was in this cocktail as well, but was removed once everything was converted to > mod_perl.) I do now recall having similar segfaults initially. The trick was > reordering the modules in Configuration so mod_gzip came last (which actually > puts it first, Apache processes the Configuration file from bottom to top). So > the relevant portions of our configure line are: > >SSL_BASE="/usr" ./configure \ > --enable-module=rewrite \ > --enable-module=ssl --disable-rule=SSL_COMPAT \ > --enable-module=auth_db \ > --activate-module=src/modules/php4/libphp4.a \ > --activate-module=src/modules/perl/libperl.a \ > --add-module=src/modules/extra/mod_gzip.c > > With this setup we have never had a problem. And with the most recent mod_gzip > (I believe it's 1.3.19.1a) it now properly plays along with mod_perl/mod_php, > and compresses their post-processing output as well. Okay, I'll take a run at compiling everything statically. I've had no end of problems though with Expat, MySQL, PostgreSQL, and Zlib libraries being linked in multiple times by multiple modules or even Apache itself. Especially expat. Grr. -jwb
Re: mod_perl, mod_gzip, incredible suckage
On Thu, 2002-02-14 at 14:32, Jay Thorne wrote: > On February 14, 2002 01:57 pm, Stephen Clouse wrote: > > On Thu, Feb 14, 2002 at 11:59:02AM -0800, Jeffrey W. Baker wrote: > > > Does mod_gzip suck or what? Some of you claim to use it. Now is the > > > time to confess. How do you get it to work? > > > > Compile it. Install it. Works brilliantly. > > > > Don't know what your problem might be. Please share offlist, perhaps I can > > help debug it. > > Ditto here. Working quite well on fairly high volume servers. Hrmm how interesting. My Apache is built with PHP (with DOM, MySQL, and Postgres) and mod_perl. With mod_gzip enabled it simply segfaults on every single request. -jwb
mod_perl, mod_gzip, incredible suckage
Does mod_gzip suck or what? Some of you claim to use it. Now is the time to confess. How do you get it to work? I installed it on a Slackware machine using the source code and apxs. It loads but segfaults on every request. I installed it on a Debian machine via apt-get and it segfaults at startup. Seems like a nasty hack. -jwb
Re: Cookie as session store
On Thu, 2002-02-14 at 06:17, Jay Lawrence wrote:
> Jeffrey - interesting point!
>
> What did you have in mind to encrypt the cookie data? Perhaps you could use
> Storable to serialize data structure then convert, crypt to scramble and
> then MIME64 to text encode?
I am not encrypting the session data in this system, because the
contents are not sensitive. I base64 encode a gzipped Storable-frozen
object, which contains another Storable-frozen object and the SHA1
digest of itself.
When the cookie is recovered, I simply decode, uncompress, thaw, check
the digest, and thaw the inner object. The code is simple:
sub realize_session {
my ($foo) = @_;
my ($i, $s);
$i = thaw(uncompress(decode_base64($foo)));
if (sha1_hex($i->{content} . BIG_SECRET) eq $i->{hash}) {
$s = thaw($i->{content});
return $s;
}
return undef;
}
sub serialize_session {
my ($s) = @_;
my ($i, $frz, $foo);
$frz = nfreeze($s);
$i = {
content => $frz
, hash=> sha1_hex($frz . BIG_SECRET)
};
$foo = encode_base64(compress(nfreeze($i)));
return $foo;
}
It's fortunate that all of these functions are fast. Base64, Zlib,
Storable, and SHA1 are all implemented in C.
> I agree with you on processing delays - that is probably the biggest
> drawback to needing to send cookies as part
> of response header. Using Template Toolkit a lot myself, I have to make a
> workaround to handle the cookie situation
> as well.
My strategy for document generation is to build a DOM tree and then
create the output by serializing the DOM to XML or HTML. So, it is
natural in this application to just set everything up before sending the
response. But I can imagine that if you wanted an intermediate page,
progress indications, and so forth you might have to jump through hoops.
> I've got a tied interface to Apache::Cookie's mostly completed - it would be
> easy to add the encryption that you describe above to
> them. See: http://www.infonium.com/perl/ for a link to Apache::Tie::Cookie.
> Featuring tied interface and lazy (demand) loading of cookie data.
Thanks!
-jwb
Cookie as session store
I have sometimes proposed or recommended schemes of storing session information in an HTTP cookie, encoded and protected by cryptographic digest. I know some people on this list have implemented similar schemes, but I have never actually had occasion to do so. Now I am doing that, and I realize the chief drawback to this scheme: all session information has to be set before generating any HTML output. The chief advantage is no requirement for server-side storage of session. For certain applications, saving all output until the session is serialized may significantly increase the latency of the first data packet in the HTTP response. -jwb
Re: Apache::Session getting DESTROYed in wrong order
On Fri, 4 Jan 2002, Ken Williams wrote:
>
> On Friday, January 4, 2002, at 02:48 AM, Gerald Richter wrote:
>
> >># Won't get cleaned up properly
> >>local %foo;
> >>tie %foo, 'Dummy', name => '%foo';
> >
> > local only make a copy of the original value and restores it at the end
> > of
> > the scope, so %foo will not destroyed, but restored at the end of the
> > scope.
> > I guess this is the reason my it still stays tied.
>
> AMS just posted this small test case to p5p:
>
> sub X::TIEHASH{bless{}}
> { local %x; tie %x, "X" } print tied %x ? "a" : "b";
>
> 5.004_03 prints "b", and 5.004_04 (and higher) prints "a". I think "b"
> is the proper behavior, at least that's my opinion.
Well, you can say I'm cold-hearted, but I think if you use every feature
Perl has in one line, you can expect trouble. Apache::Session has a
history of this. With every Perl < 5.6, it cause a segfault when calling
die() from within TIEHASH.
-jwb
Re: Apache::Session getting DESTROYed in wrong order
On Mon, 31 Dec 2001, Ken Williams wrote: > Hey, > > I'm having problems with Apache::Session, the symptom is that none of my > data is getting written to the database. It's not the nested-data > problem, since I'm not using any nested data structures. > > After some investigation, I've discovered that the > Apache::Session::Store::MySQL::DESTROY routine is getting called before > the Apache::Session::MySQL::DESTROY routine, so when the latter is > called it doesn't have any way to write to the database. > > I think Perl is supposed to guarantee that the outer object's DESTROY is > called before the inner object's, but I think maybe this guarantee > doesn't extend to the "global destruction" phase. So I'm wondering why > the session is getting cleaned up in global destruction rather than > refcount destruction. I've declared %session as a locally-scoped > variable, so it should evaporate before global destruction, unless it's > got circular data structures or something. Anyone know what might be > going on? > > This is Apache::Session version 1.53. > > Note: this problem isn't related to mod_perl, but IIRC this list is the > proper place for discussing Apache::Session. Ken, Yeah this is the right list for Apache::Session discussion, and Perrin is the unofficial guy who answers all the questios, since I don't pay that much attention. This seems like a really weird problem. The Store module is destroyed while another module still has a reference to it. Unfortunately for you and I, the only conclusion I have been able to draw is that Perl's DESTROY magic is unreliable. We have modules in my company where things are randomly undefined in DESTROY subroutines, because the DESTROY of the referenced thing has already been called. So, somewhere in Perl there is a bug, possibly an off-by-one in the reference counting. Anyway you can work around it. Explicitly call tied(%session)->save() when the time is right. -jwb
Re: Cache::* and MD5 collisions [was: [OT] Data store options]
On Thu, 2001-11-08 at 10:11, Barrie Slaymaker wrote: > On Thu, Nov 08, 2001 at 08:59:55AM -0800, Bill Moseley wrote: > > Hi, > > > > > > I'm looking for a little discussion on selecting a data storage method, and > > I'm posting here because Cache::Cache often is discussed here (along with > > Apache::Session). And people here are smart, of course ;). > > > > Basically, I'm trying to understand when to use Cache::Cache, vs. Berkeley > > DB, and locking issues. > > Even a bit more OT: one thing to watch out for, especially if you plan > on caching a *lot* of data, is that the Cache::* modules did not do > collision detection on MD5 collisions the last time I looked. Forgive > me if that's changed recently. > > The probability is extremely low, but they can and do occur "in the > wild" (I won't bring anyone's name up here :). In other words, it's a > remote possibility that one URI might serve up another's content if the > two hash keys map to the same MD5 value. > > Given an infinite number of web monkeys using Cache::* and an infinite > number of user monkeys clicking on links... You could switch to SHA1. SHA1 collisions will be much more rare than MD5 collisions. -jwb
Re: ANN/RFC: Apache::Session::Generate variants
On Fri, 12 Oct 2001, Gerald Richter wrote: > > > > If you have other things on your mind, that's fine. That's why I > > suggested you should consider letting someone else maintain it. I know > > I'm not the only person frustrated by the current state of affairs. > > > > My solution to this problem is, that I have created a package named > Apache::SessionX which subclasses Apache::Session and contains all the > eXtentsion I need (most of them for Embperl, but they are also usefull > outside of Embperl). This also contains a replacement for > Apache::Session::Flex which can be configured via Makefile.PL and make test > is testing if this really works on the system. See, Gerald is a smart fellow, and I like that he never threatened to take over my modules. -jwb
Re: ANN/RFC: Apache::Session::Generate variants
On Thu, 11 Oct 2001, Dave Rolsky wrote: > On Thu, 11 Oct 2001, Jeffrey W. Baker wrote: > > > Well, you guys are touchy lot! My releases are no less frequent than > > releases of DBI or even mod_perl. So just chill out, I sometimes have > > other things on my mind. > > I don't know about touchy so much as frustrated. Apache::Session is very > widely used but it doesn't feel well supported. > > Comparing it to DBI or mod_perl seems a bit silly. It is not as widely > used as either and is far less complex. > > My big concern is that there is a fatal error in Apache::Session::Flex > that makes it completely unusable. You've known about this for at least > 9-12 months but you haven't bothered to release a simple bugfix release > for it. Its a 3-4 line change! Then package it up, send me the tarball, and I'll upload it to CPAN. Repeatedly sending me patches isn't any more likely to get me to pay attention to it. Regarding Flex, nobody uses it. It is for debugging. If you have a particular variant of Flex that you use all the time (very likely), you can code up a 6-line module to make a real implementation like all the other session modules. Flex is for debugging, period. Version 1.54 is uploaded to CPAN so go nuts. -jwb
Apache::Session 1.54 released
Apache::Session 1.54, also know as the "you impatient bastards" release, has been uploaded to CPAN. Changes in this release include: Fix ID validation in Flex Move from MD5 to Digest::MD5 Include new generators ModUniqueId and ModUsertrack -jwb
Re: ANN/RFC: Apache::Session::Generate variants
On Thu, 11 Oct 2001, Tatsuhiko Miyagawa wrote: > On Thu, 11 Oct 2001 01:06:33 -0500 (CDT) > Dave Rolsky <[EMAIL PROTECTED]> wrote: > > > Jeff, if you're still maintaining this package it'd be nice to put out a > > new release. If not, it'd be good to give it to someone else. Hell, I'll > > volunteer if no one more interested comes along. I don't have any big > > plans for it but I can at least integrate patches and such. > > > > Apache::Session is in use in a lot of places and it would be good to have > > an active maintainer. > > ++1. And I don't mind taking over, if nobody else wants to. Well, you guys are touchy lot! My releases are no less frequent than releases of DBI or even mod_perl. So just chill out, I sometimes have other things on my mind. -jwb
Re: Using DOM to build your output documents
On Wed, 3 Oct 2001, DeWitt Clinton wrote: > On Wed, Oct 03, 2001 at 04:43:41PM -0700, Jeffrey W. Baker wrote: > > > I'd also like to hear people's opinions on XML::DOM (I think it > > stinks and I've replaced it with a C DOM implementation). > > You just proved that you already know everything you need to on the > subject of XML::DOM. :) > > Seriously though, what C DOM implementation did you choose and how did > you integrate it with your Perl code? I whipped up a DOM from scratch that supports Document, DocumentFragment, Node, DOMImplementation, NodeList, and Element, then I wrapped some Perl around it. It is a lot less stressful when the W3C already specified the API for you :) -jwb
Using DOM to build your output documents
I believe that the canonical way to output a document using any web
scripting language (Perl CGI, mod_perl, PHP, ASP, etc.) is to simply print
out your markup, like this fictional example:
while (my $row = $sth->fetchrow_arrayred()) {
print "$row->[0]$row->[1]\n";
}
There are two main drawbacks to this style of output. The first is that
print() can mean a trip down the output stack and back up. The second is
the unavoidable linearity output. There is no way to back up and change
something once you have decided to print it.
In my more recent web sites, I have been taking a slightly different
approach by building the document from scratch using the DOM, and printing
the DOM tree out at the end of the program. I perceive several
advantages:
* I can add or remove content and markup anywhere in the document at any
time.
* I avoid I/O functions until the final batch I/O at the end.
* I never have markup errors because the DOM tree always prints itself out
properly.
I'd love to hear any other experiences with using the DOM to build output
from scratch. I'd also like to hear people's opinions on XML::DOM (I
think it stinks and I've replaced it with a C DOM implementation).
-jwb
Re: Mod_perl woes
On Tue, 18 Sep 2001, brooks roy wrote: > Hello, I have just installed mod_perl into my Apache 1.3.20 install :).. I > have apache+mod_ssl+mod_frontpage+php. > > When ever I apachectl start it start up fine but when I try to load a > webpage, it says it cannot access the specified URL, here is a capture of > the error_log. Three ideas: 1) Make sure that Apache, Perl, mod_perl, mod_php, and whatever else are all compiled with large file support, or without it, consistently 2) Make sure that PHP isn't using its built-in mysql driver 3) Check the order of your module loading Personally, I think you should just build php and perl in statically instead of via DSO. -jwb
Re: Apache::Session not updating session
On Tue, 14 Aug 2001, Todd Finney wrote: > Isn't that what tied(%session)->make_modifed; is for? Yep.
Re: Not embedding SQL in perl (was RE: [OT] Inspired by closingcomments from the UBB thread.)
On Thu, 2 Aug 2001, Gunther Birznieks wrote: > When you've had your fill of wrestling over mySQL vs PostGres and stored > procs versus inline SQL (I know I have long ago) > > You guys should definitely read the following: > > http://www.ambysoft.com/persistenceLayer.html > > One of my current coworkers turned me on to this. I have found it to be one > of the best series of articles related towards what it takes to abstract > database away from your object layer and the various levels at which it > makes sense to do so. > > You may find the design a little complex, but Scott pretty explicitly > states that this is what is necessary for a *large* system. You can always > go down a less complex path by choice if you feel your programs aren't > complex enough to need the full Persistence Layer structure he advocates. I've worked with Scott Ambler, and I could record everything Scott Ambler knows about actually devleloping large systems on the head of a pin, using a magic marker. That guy is a hopeless academic without the slightest clue of how to actually make software happen. Here's the brutal truth about persistance "abstractions" using an RDBMS backing store. At some point, your DBA is going to come up to you and tell you that you code is too slow. You need to rewrite some SQL queries to use a different index, or some sorting hints, or whatever. You will realize that you need to pass some extra information down through your abstraction layers to make it all happen. After that happens twice or thrice, you will slowly come to realize that your abstraction is really no abstraction at all: every time the schema changes, the top level interface needs to change as well. -jwb
Re: What counts as a real DBMS?
On Wed, 1 Aug 2001, Philip Mak wrote: > On Wed, 1 Aug 2001, Henrik Edlund wrote: > > > And while we are discussing "not cutting corners", those who still use > > MySQL should switch to a real DBMS before they even think of abstracting > > the SQL away from their Perl code. > > > > That people still use MySQL really shows how many lusers there are with > > computers that try to develop real software. I said _try_. > > What would you consider to be a real DBMS? Sybase and Oracle obviously, > but I actually am the hypothetical programmer with a 233MHz machine with > 64 MB RAM (hey, it runs emacs fine :/) on a shoestring budget who is > mostly limited to using freeware tools. > > What about PostgreSQL and Interbase? Do those have the features of a > 'real' DBMS? Yes. Postgres has integrity constraints triggers, stored procedures, a well-known extension interface, transactions, high concurrency, and all of ANSI SQL. PostgreSQL is Free. -jwb
Re: Apache=SCALAR(?????)
On Fri, 27 Jul 2001, Greg Lontok wrote: > hello, > > I recently changed a username/password check script to mod_perl, however > when under mod_perl, I noticed that failed logins with the correct username > and password combination show the password in the log as Apache=SCALAR(???), > i.e. Apache=SCALAR(0x2d9f74). What is mod_perl doing here to my password > parameter. This is a basic Perl question. "Apache=SCALAR(0xcafebabe)" means that the thing you printed is scalar reference to an object, blessed into the Apache class, and its memory address is 0xcafebabe. -jwb
Re: BOF?
On Thu, 19 Jul 2001, brian moseley wrote: > On Tue, 17 Jul 2001, Ask Bjoern Hansen wrote: > > > Sunday evening where? > > sounds like the hotel bar is the only real option. i'll be > there 8.30-9pm i guess. my flight arrives at 10:15 so i'll drop by the bar at 11:30 or so. -jwb
Re: BOF?
On Sat, 14 Jul 2001, brian moseley wrote: > On Sat, 14 Jul 2001, Ken Williams wrote: > > > I just noticed that there's no mod_perl BOF listed at > > http://conferences.oreillynet.com/cs/os2001/pub/10/bofs.html . > > Is one scheduled? If not, let's get one together. > > speaking of which. there should be an opening night piss-up, > eh? somebody that knows the area should propose a place. I'm sure SD hasn't got anything nearly as classy as the Eagle and Anchor or whatever the place in Monterey was. Looks like the conference hotel might be quite a ways from anything interesting. -jwb
Help, no room at the inn!
Howdy, Because I am an Authentic 99.44 Percent Pure Jackass(tm) I haven't booked a room at the O'Reilly convention fast approaching. I called the hotel today and all they were able to offer me were some overpriced suites that I don't want. I would be very grateful if one of you good fellows with whom I have shared this list for so long, and who booked a double room for themselves, would generously allow me to occupy the other bed and split the room rate. Please email me! -jwb
Re: Apache::Session install errors
On Mon, 2 Jul 2001, Bakki Kudva wrote: > this may be slightly OT but when try to install Apache::Session I am > getting... I suggest "force install Apache::Session" -jwb
Re: @INC?
On Mon, 2 Jul 2001, Gareth Hughes wrote: > Hi All > > I've successfully configured Apache on Win2k. One of the sites I host uses a > lot of perl so mod_perl was an obvious addition. > I know nothing about perl but I'm pretty sure mod_perl is installed and > running correctly except for being able to reference the correct > directories. When I access a .pl page I get a 500 internal server error > returned and the error log shows this: > > [Sat Jun 30 15:30:08 2001] [error] Can't locate HTMLfile.pm in @INC (@INC > contains: .. powershift D:/Perl/lib D:/Perl/site/lib . c:/apache > group/apache/ c:/apache group/apache/lib/perl) at > d:/mmwebs/ps/scripts/powershift/veh_sup/approved-vehicles.pl line 31. > BEGIN failed--compilation aborted at > d:/mmwebs/ps/scripts/powershift/veh_sup/approved-vehicles.pl line 31. > > I've added the module and directory directives in the httpd.conf file and if > I move the HTMLfile.pm (and a bunch of other .pm files) into > D:/Perl/site/lib the scripts run correctly. Unfortunately the scripts > eventually reference other files that can longer be found because the .pm > files have moved. Also, moving the files is far from ideal for ftp access > etc. > > Shouldn't the scripts be looking in the directory they were run from as they > did before mod_perl? Does anyone know if this is a mod_perl configuration > issue or do the perl scripts need some additions to be mod_perl compatible? mod_perl loads the scripts up into subroutines for execution. Thus, Perl is not running them the way they would normally get run, and things like present working directory might not behave the way you expect. To add to @INC, you can either use "PerlSetEnv PERL5LIB /whatever" to httpd.conf, or you can use a startup script (canonically startup.pl) and include "use lib '/whatever';" therein. Best, Jeffrey Baker
Re: where to report apache::session 1.53 bug ?
On Thu, 28 Jun 2001, Iwan Garnadi wrote: > I don't know where to report apache::session bug , because I sent to the > author , I didn't get any reply yet Maybe you will have to wait more than four days... -jwb
Re: Where do i install ActivePerl to?
On Fri, 22 Jun 2001, Castellon, Francisco wrote: > Hi people: > > I am trying to install Active Perl in order to run mod_perl in apache. I am > running on Windows98SE and the latest version of apache. > So is there a particular directory that i have to install Active perl to? or > is anywhere just fine? > The other thing as well is that i have been hearing alot about installing > mod_perl through ActivePerl by downloading a PPD file of some sort, how do i > do this? I think the canonical place to install ActiveState's product is C:\Perl -jwb
What the user in user agent means
Why are we talking about tracking again? The user agent acts on behalf of the user. It is their agent. It is not your agent. Your content or program is a guest of the user agent, not its master. Learn to work with the web not against it.
Re: Apache::Session not storing changes to hashref
On Tue, 22 May 2001, Chris Thompson wrote:
> I'm at wits end, I'm hoping someone can tell me what's wrong.
>
> This is Apache 1.3.19, Redhat 6.2, modperl 1.25, apache::session 1.53
> and MySQL 3.23.36.
>
> (This is also happening inside HTML::Mason 1.03, but I dont think that has
> anything to do with it. I've crossposted to the mason list in case anyone
> there has seen this behavior, but what I'm doing isnt really out of the
> ordinary, so I dont think it's Mason related)
> That's there because before I did the Dumper, I populated the %s with the
> data I had on the term. Each term is read from Apache::Request into
> @term. (Yes, the orders match)
>
> so I do...
>
> my $c=0;
> foreach my $term (@term) {
>$s{regdomains}->[$c++]->{term} = $term;
> }
Check the Apache::Session docs. Your changes below the toplevel will not
be noticed. You must either change something at the top level (like a
timestamp or serial number), or you must frob the session object via
tied(%session)->make_modified();
Docs are your friend and I spent a lot of time writing them.
-jwb
Re: Preventing duplicate signups
On Thu, 17 May 2001, Rob Bloodgood wrote: > So, like many of you, I've got a signup system in place for bringing on new > customers. > > My signup script is reasonably straightforward. I use CGI::Validate to make > my parameters pass muster (along with a little judicious JavaScript on the > signup form), Apache::Session::Oracle to maintain state between the multiple > pages of the signup, CGI::FastTemplate to print a pretty success page, and > DBI to create the account records at successful creation. When you send out the signup form, include a random 32-character hexadecimal string as a hidden input, and record in your database that the code has been sent out. When the form is submitted, ensure that the code which accompanies it is valid, by looking in the database. Then mark the code as already used. When the user reloads, your program will see that the code he is sending was sent before, and can ignore his duplicate request. Jeffrey
Re: Where exactly is the Perl interpreter?
On Thu, 10 May 2001, Issac Goldstand wrote: > I was just wondering- where exactly is the Perl interpreter in > mod_perl 1.25 (for Apache 1.3) and where will it be in mod_perl 2 > (Apache 2.0)? I assume in Apache 1.3 it's in shared memory, but I > want to double check... This depends strongly on how your platform works. On Unix and friends, the Perl interp is in each Apache process. However, the various interps may actually reside in the same physical memory on your computer, because of a kernel feature called copy-on-write. Look it up on Google if interested. It would be incorrect to say that Perl is in shared memory on Apache 1.3/Unix. Although the memory may in fact be shared, it is not shared memory in the sense of shmctl, shmget, and shmop(2). -jwb
Re: Regarding modperl installation (fwd)
On Sat, 5 May 2001, Stas Bekman wrote: > Gosh, sometimes I feel like I've forked the mod_perl mailing list :( You get the most astonishing emails from these consultant types. "Infosys is a world leader in providing IT consulting and software services[.]" [1] >From the world consulting leader comes this amazing request. The requestor is working on an important assignment, and mod_perl is very critical to the assignment. No doubt the requestor needs some help, else his client might get snippy. As they should, since the person assigned to this important project has obviously never installed a Perl module before, and cannot even read the first line of stdout, exhorting him to install Perl 5.004_04. Anyway, we know how this world leader feels about Perl: "Serious CGI-based web applications use native executables, since scripting languages are very slow." ...and web server APIs, like the one mod_perl exposes: "For web-bases software product, it is not worth [it] to risk the chances of crashing the web servers, and portability is bad, leading to very high development costs relative to other means." [2] Even when I am in a good mood, paid consultants looking for free advice ruffle my feathers. When I'm in a bad mood, it warrants a response. -jwb [1] http://www.infy.com/ [2] http://www.infy.com/corporate/thought-papers/technical_alternatives_jan18.doc > > -- Forwarded message -- > Date: Fri, 4 May 2001 16:26:16 +0530 > From: Qazi Firdous Ahmed <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Regarding modperl installation > > Hi.. > > After having gone through your installation steps, i tried installing > with the same during which i encountered a couple of issues to be > resolved. I would request you to guide me in this regard. > I have attached a file wherein the results of Makefile command and the > issues are to be seen. > Further i am using Apache Version 1.3.14, modperl version 1.25, > libwww-perl5.53 which i downloaded from cpan and apache.org. > I tried to put the various missing modules in one of the > directories(directories given by perl-v command), but still it is giving > the errors. > This is very critical for the project i am working on. > Hope to get your expertised guidance for the same. > > Thanking you in anticipation > Qazi Firdous Ahmed > >
Re: Exception modules
On Mon, 30 Apr 2001, Matt Sergeant wrote: > On Mon, 30 Apr 2001, Jeffrey W. Baker wrote: > > > Yes precisely. It used to be that you could only die() with a string, but > > 5. gave us die() with a reference to an object and at that moment > > the system was complete. The creation of a rational exception object type > > is left to the discretion of the system designer (thankfully). > > Well actually I personally would prefer proper exception semantics, but > unless someone re-writes Error.pm (or whatever) to be implemented using > Filter, then we're stuck with closures, which I'll avoid thank you. > > The things I don't like are: > > You currently have to do two blocks, one if ($@), and then > if($@->isa(...)) inside that. That's too much typing, when Perl is so > renouned for it's succinctness (is that a word?). > > The second thing is no finalize/always clause (you can sort of emulate it, > but it's not quite guaranteed like it is in languages that implement it > properly - we discussed this yonks ago on perl-friends, I'll try and dig > up the discussion if you want). > > The whole $@->isa() thing, it's just plain ugly, and doesn't really look > like exception handling - it looks like botched up OO code. It can/should > be more structured IMHO. > > It's also another case of far too many ways to do it, causing people's > perl code to look different everywhere, which is bad for maintainence. Well, the nice thing about the way Perl does it is that you can have your way, and boy am I glad I don't have to do it that way, too. I have learned that errors from down in the call stack are very rarely conditionally recoverable. If I call obj->method(), and it throws an exception, there are few situations where the cause of the exception matters at all. In most cases I will just not handle the exception, and it will bubble up. In some cases I might want to log. In others I might want to retry, or try plan B. But, very rarely do I want to branch on the type of exception. Right now I cannot in fact think of any program I have written that branches on the type of exception. Java encourages this with multiple catch blocks, but I think it is stupid and anyway the catcher usually is not the primary source of knowledge about what the hell happened. Think of it: the called program had to make a decision about what exception to throw, and now the caller is trying to decode that exception. I believe that decisions should be made at the place in the program that has the most relevant information about the decision. If you try to encode information into the exception object, you are encouraging some other part of the program to make a less-informed opinion. My coding style dictates that a function or method will always do everything in its power to succeed. If it returns an error code or throws an exception, that means permanent failure as far as that function is concerned. In my C code, I usually find that I only need two values for my return value: FAILURE and SUCCESS. I rarely need anything beyond that. The explicit exception declarations in Java piss me off, because they cause maintenance headaches. Say you have a twenty level call stack. At depth 0, you catch Exception, at depth 5, you catch FooException. Let's say that a package API changes and depth 15 now need to throw BarException. At some level, you now have to explicitly handle BarException. You either have to do it at depth 14, or you have to change the declaration of every method up the call stack to the depth that *does* handle BarException. This is more work than it needs to be. Regards, jwb
Re: Exception modules
On Mon, 30 Apr 2001, Matt Sergeant wrote:
> On Mon, 30 Apr 2001, Jeffrey W. Baker wrote:
>
> >
> >
> > On Mon, 30 Apr 2001, Matt Sergeant wrote:
> >
> > >
> > > > [1] for my Perl exception package (yes, another one :) which, in its
> > > > development version, now mostly does the Right Thing for mod_perl. See
> > > > http://sourceforge.net/projects/perlexception/ for the curious.
> > >
> > > Since I'm doing the mod_perl exception handling talk at TPC, I feel
> > > obligated to ask about this...
> > >
> > > It doesn't seem any different from Error.pm to me, except in syntax. Maybe
> > > you could expand on why/where it is different?
> >
> > I tried using some different exception packages in the past. What I
> > realized is, die() and eval {} ARE Perl's exception handling mechanism.
> > die() and eval {}, together, have complete exception throwing and handling
> > functionality. As a bonus, they lack Java's exception bondage and
> > discipline.
> >
> > So, what's wrong with die() and eval {}?
>
> Nothing, IMHO. In fact I've now switched away from using Error.pm's
> try/catch syntax, because it creates closures and it's really easy to
> generate memory leaks that way with mod_perl. But I still use Error.pm's
> exception object structure...
>
> Without some sort of structured exception handling, you don't know exactly
> what type of exception was thrown. For example, in AxKit I need to know in
> certain places if an IO exception occured, or if it was some other kind of
> exception. I could do this with regexps, but then I'm relying on people
> using the right strings in their error messages. Plus exception objects
> can give you a stack trace, which eval catching a string can't (well, it
> kinda can in a few ways, but not in quite as clean a manner).
>
> Try it though, you might be surprised you like it. (unless by die() and
> eval{} you mean you're already using exception objects, in which case I'm
> preaching to the choir ;-)
Yes precisely. It used to be that you could only die() with a string, but
5. gave us die() with a reference to an object and at that moment
the system was complete. The creation of a rational exception object type
is left to the discretion of the system designer (thankfully).
-jwb
Re: Exception modules
On Mon, 30 Apr 2001, Matt Sergeant wrote:
>
> > [1] for my Perl exception package (yes, another one :) which, in its
> > development version, now mostly does the Right Thing for mod_perl. See
> > http://sourceforge.net/projects/perlexception/ for the curious.
>
> Since I'm doing the mod_perl exception handling talk at TPC, I feel
> obligated to ask about this...
>
> It doesn't seem any different from Error.pm to me, except in syntax. Maybe
> you could expand on why/where it is different?
I tried using some different exception packages in the past. What I
realized is, die() and eval {} ARE Perl's exception handling mechanism.
die() and eval {}, together, have complete exception throwing and handling
functionality. As a bonus, they lack Java's exception bondage and
discipline.
So, what's wrong with die() and eval {}?
-jwb
Re: an unusual [job request] + taking mod_perl to the commercialworld
On Sat, 28 Apr 2001, Gunther Birznieks wrote: > Well, you know how I feel. :) But the others don't so... > > I believe the most crucial and missing approach is to put resources into > making ready-made applications that work on mod_perl rather than core > mod_perl itself. This is also a problem on Linux, but that's another story. > A quantity of applications for mod_perl or that demonstratively show that > using mod_perl is a benefit (ie fast) is necessary (and I don't mean tech > products like AxKit -- which are great but not what I am talking about) I will be demonstrating a canned micropayment system at O'Reilly in San Diego this year. The reference implementation for the content provider uses mod_perl. I think you are right that most people in non-tech business want a solution that works immediately, rather than a toolbox. The toolbox is already there with Apache, mod_perl, and DBI, now application developers can just step up and deliver. -jwb
Re: Loading Index.pl as the Root File
On Mon, 23 Apr 2001, Al Morgan wrote: > I've been studying Slash to better understand mod_perl. I think I > understand everything that happens in the config file, except for this: That is probably the single worst way to learn about mod_perl. Slash is the only program that makes me physically ill. It is the single worst piece of programming ever released upon the world. > > > SetHandler "perl-script" > PerlHandler Slash::Host::slashcode::rootHandler > > The "~" means to use a regular expression to match the path part of the URI. The regular expression "^/$" matches only exactly the string consisting of a single slash character, so there is no point to using a regular expression there (as far as I can tell). Also, in Apache 1.3, is preferred over . At least now we know why slashdot is so slow: regex matchine on every request. > Apparently, whenever the user reqests the root document (normally > index.html), it calls rootHandler, which redirects it to index.pl. My > question is: What does the ~ "^/$" mean? I don't quite understand how > they are doing what they're doing. -jwb
Re: Cutting down on the DEBUG bloat...
On Tue, 10 Apr 2001, Paul Lindner wrote: > Now, my question is: Is there some trick I could use to retain the > simple syntax: > > debug "foo bar"; I always liked using a preprocessor to turn debug code on or off. ePerl is OK, and Perl can of course be its own preprocessor. -jwb
Re: returning HTTP error code
On Thu, 5 Apr 2001, Helios de Creisquer wrote:
> Hi !
>
> I've got a mod_perl script calling an external program which
> use much memory. And I would like to send a 503 instead of
> calling this external program when there is less than xxxMB
> of memory free.
>
> Is mod_perl provides this ability to decide to send
> an HTTP return code or another ?
sub handler {
my $r = shift;
$r->status(503);
$r->send_http_header;
return OK; #or return SERVER_ERROR; depends on how want to do it.
}
-jwb
Re: how to prevent ie ( et al ) from resubmitting POST info
On Thu, 29 Mar 2001 [EMAIL PROTECTED] wrote: > Anyone have any tricks up their sleeve to prevent the following: > IE, on opening a new browser windows, or on revisiting through history a > page which submitted some post data, will re-post that data, > which causes me problems, as POST triggers my music player window, > with a random mix from the post parameters. > Netscape does this too, but only on reload. > > It's tricky to have a flag disallowing reposts, because it's hard to > differentiate between an accidental one and a real one. > > I guess I'm just wondering if anyone has thought hard about this here. You oculd put a one-time key in the form values.
Re: Apache::Session::Postgres Segmentation Fault Addendum
On Thu, 29 Mar 2001, Victor Michael Blancas wrote: > I'm using Apache::Session::Postgres with Apache::ASP. > I'm getting a Segmentation Fault whenever I do a $dbh->disconnect at the > end of the script. When I comment out the the $dbh->disconnect however, I > don't get any errors. Having a script without a $dbh->disconnect at the > end is wrong isn't it. Anyone encountered this before? > > I just tested it as a simple perl script on the command line. I'm still > getting a core dumped Segmentation Fault whenever I do a disconnect at the > end of the script. Sounds like a Postgres bug. Can you hook up GDB and get a stack trace? -jwb
Re: [JOB] Perl expert for hire
On Mon, 26 Feb 2001, Jeffrey W. Baker wrote: > I am available for contract or permanent work beginning immediately. I am > an expert in Perl programming, have a long history of experience with > mod_perl, and can write Perl extensions in C. I am also a productive C > programmer and a passable Java programmer. Recently I have begun dabbling > in Apache core programming and embedding the Perl engine in C programs. > > You may view my resume at http://atari.saturn5.com/ Boy, I feel cool now. The real link is: http://atari.saturn5.com/~jwb/resume.html Those pesky URLs. -jwb
[JOB] Perl expert for hire
I am available for contract or permanent work beginning immediately. I am an expert in Perl programming, have a long history of experience with mod_perl, and can write Perl extensions in C. I am also a productive C programmer and a passable Java programmer. Recently I have begun dabbling in Apache core programming and embedding the Perl engine in C programs. You may view my resume at http://atari.saturn5.com/ Best regards, Jeffrey Baker -- [EMAIL PROTECTED] 415.279.0768
Re: [RESEND] seg fault with Apache::URI ... weird
On Fri, 9 Feb 2001, Nick Tonkin wrote: > > Hi Jeff, > > Thanks for your feedback. > > I wonder if you noticed that this code was from the Auth/Access stuff > you did for me a while back ... so I'll patch mine but you might want to > take a look at the places you are using it ... Actually, I didn't. Does this mean that strcasecmp(3) on FreeBSD doesn't segfault when given NULL pointers? Or does this mean that the version of Apache at the time (1.3.6 and 1.3.9) didn't have this problem? The code in Apache hasn't changed since then, so I assume a difference between BSD and Linux libc. Cheers, Jeffrey
Re: [RESEND] seg fault with Apache::URI ... weird
On Thu, 8 Feb 2001, Nick Tonkin wrote:
>
> Hi all,
>
> No response on this so here it is again, any clues appreciated:
>
> I am encountering a weird problem with Apache::URI ... consider, please,
> this test handler:
>
> package WM::Test;
>
> use strict;
>
> sub handler {
> my $r = shift;
> my $uri = Apache::URI->parse($r, $r->uri);
> $uri->hostname($r->get_server_name);
> $uri->port($r->get_server_port);
> print $uri->unparse;
> }
>
> 1;
> __END__
>
> As written, this causes a seg fault every time. Commenting out _either_
> the $uri->hostname assignment _or_ the $uri->port assignment solves the
> problem, or even changing the call to one or other of the methods from an
> assignment to a read. But when both methods are assigned new values, seg
> fault.
>
> This code has worked fine for two years or more on my FreeBSD boxes; this
> is on Linux RedHat 7 ... dunno if that makes a difference.
It doesn't make a difference. Segfaults for me on Slackware-current, too.
However, I would suggest avoinding RH 7.0 and its buggy compiler!
I've debugged the problem, but have no solution:
my $uri = Apache::URI->parse($r, $r->uri);
This calls ap_parse_uri_components(), which is responsible for setting
the scheme, hostname, user, password, port, path, etc. But, the scheme is
not getting set, because the request line only contains "/path" or such.
$uri->hostname($r->get_server_name);
$uri->port($r->get_server_port);
These work fine.
print $uri->unparse;
This calls ap_unparse_uri_components(). If there is a hostname but no
scheme, ap_unparse_uri_components() will pass a null argument to
strcasecmp, which will cause an invalid memory access and SIGSEGV. You
can work around the problem by including $uri->scheme('http'); with the
other accessor methods. In the long run this is probably a bug in Apache.
If you read src/main/util_uri.c in Apache, you can see why commenting out
one accessor avoids the crash.
Regards,
Jeffrey Baker
Re: Redirection Location MUST be absolute (was Re: Send a cookie,AND a redirect ?)
On Thu, 8 Feb 2001, Robert Landrum wrote: > If all browsers followed the W3 standards the world would be a better > place... > > They say "...field value consists of a single absolute URL." > ^^^ I think > they mean URI because the example says "absoluteURI", not URL. > > An absolute URI is > > /some/location No, that is not an absolute URI. absoluteURI is defined unabiguously in RFC 2068: absoluteURI= scheme ":" *( uchar | reserved ) So, you see, an absoluteURI MUST contain the scheme. > > But so is > > http://www.somehost.com/some/location > > Both are valid URIs and both absolute. One is more qualified than the > other. No. > A relative URI is > > some/location > > which is incorrect, and not what I meant in my message. > > Which brings us to the next point... > > By using relative *URLs* such as /some/location, you avoid changing > the location field in the browser window, which is often desired. If > you use an absolute *URL*, the location field changes to the absolute > URL. This is the desired behavior. > You can try it with a simple perl script CGI. > > #!/usr/bin/perl print "Location: /some/location/\n\n"; > > or > > #!/usr/bin/perl print "Location: > http://somehost.com/some/location/\n\n"; -jwb
Redirection Location MUST be absolute (was Re: Send a cookie, ANDa redirect ?)
On Thu, 8 Feb 2001, Robert Landrum wrote: > The problem is that Apache does not put the "Set-Cookie" before the > "Location" when generating headers. To fix this, you need to build > the header yourself. I've found that this works with Netscape and > IE, but with IE, the place where you redirect to does not have access > to the cookie that you just set. All subsequent pages are able to > read the cookie... It's a bug in IE. > > > my $cookie = Apache::Cookie->new($r, > -name => "MYCOOKIE", > -value => "VALUE", > -path => "/some/cookie/path" > ); > > my %headers = ( > "Location" => "/some/redirect/location", I'd like to mention that the Location header MUST be absolute, NEVER relative. Absolute means that it must include the scheme! http://www.w3.org/Protocols/rfc2068/rfc2068 14.30 Location The Location response-header field is used to redirect the recipient to a location other than the Request-URI for completion of the request or identification of a new resource. For 201 (Created) responses, the Location is that of the new resource which was created by the request. For 3xx responses, the location SHOULD indicate the server's preferred URL for automatic redirection to the resource. The field value consists of a single absolute URL. Location = "Location" ":" absoluteURI An example is Location: http://www.w3.org/pub/WWW/People.html -jwb
Re: Apache::Session::Postgres error
On Tue, 16 Jan 2001, Edmund Mergl wrote: > Todd Finney wrote: > > > > I'm using Apache::Session::Postgres to track sessions via > > cookies. When I access a page, the cookie is correctly > > sent by the server, and accepted by the client. However, > > on the second request, I'm getting a 'Object does not exist > > in data store' error. > > > > It looks like the session is not being stored in the > > database, although I can't figure out why. When running > > postmaster -d 2, I get the following output: > > > > > This problem has been reported several times. > find below the explanation of Francis J. Lacoste > from Sun, 17 Oct 1999. > > Edmund > > > > This is because the DBIStore insert the encoded session data as > binary data. PostgreSQL doesn't like that. You have to modify > Apache::Session::DBIStore (or better implement a PGStore) > to uuencode the session data. You can use for that MIME::Base64 > or better yet > > pack( "u*" ) and unpack ( "u*" ). That's not true anymore. Apache::Session 1.5+ have UUE and MIME modules for talking to Pg and other binary-averse backing stores. UUE is automatically selected when Pg is in use. -jwb
Re: Apache::Session::Postgres error
On Tue, 16 Jan 2001, Todd Finney wrote:
> I'm using Apache::Session::Postgres to track sessions via
> cookies. When I access a page, the cookie is correctly
> sent by the server, and accepted by the client. However,
> on the second request, I'm getting a 'Object does not exist
> in data store' error.
Looks like it could be a transaction handling problem. I'll have a look
tonight. -jwb
>
> It looks like the session is not being stored in the
> database, although I can't figure out why. When running
> postmaster -d 2, I get the following output:
>
> started: host=localhost user=postgres database=sessions
> InitPostgres
> StartTransactionCommand
> query: begin
> ProcessUtility: begin
> CommitTransactionCommand
> StartTransactionCommand
> query:
> INSERT INTO sessions (id, a_session)
> VALUES
> ('8efc89ae6006cfdfa24d12eba4019526','AwMBCiA4ZWZjODlhZTYwMD
> ZjZmRmYTI0ZDEyZWJhNDAxOTUyNlgLX3Nlc3Npb25faWRY
> ')
> ProcessQuery
> CommitTransactionCommand
> StartTransactionCommand
> query: rollback
> ProcessUtility: rollback
> CommitTransactionCommand
> StartTransactionCommand
> query: begin
> ProcessUtility: begin
> CommitTransactionCommand
> StartTransactionCommand
> query:
> UPDATE sessions SET a_session =
> 'AwMAWA==
> ' WHERE id = NULL
> ProcessQuery
> CommitTransactionCommand
> StartTransactionCommand
> query: commit
> ProcessUtility: commit
> CommitTransactionCommand
> StartTransactionCommand
> query: begin
> ProcessUtility: begin
> CommitTransactionCommand
>
> It appears to be rolling back the insert transaction, but I
> don't know why. The session does not appear in the
> database, and all subsequent requests fail. I've tried
> undef'ing, untie'ing, and make_modified (and various
> combinations) on the hash, to no avail.
>
> The whole handler is below, in case you're interested.
>
> thanks,
> Todd
>
>
> package LocalSites::Session;
>
> use strict;
> use Apache::Constants qw( DECLINED);
> use Apache::Log;
> use Apache::Session::Postgres;
>
> sub handler {
> my $r = shift;
> my $log = $r->server->log();
> my $session;
> my $use_cookies = $r->dir_config->{'UseCookies'} || 0;
>
> if ($use_cookies) {
> $log->error("Session: Begin Transaction Using
> Cookies");
> $session = $r->header_in('Cookie');
> $session =~ s/SESSION_ID=(\w*)/$1/;
> $log->error("Session: ID is $session");
> } else {
> $log->error("Session: Begin Transaction Using Path
> Info");
> # Placeholder for code to extract SESSION_ID from
> the path
> }
> undef $session if ! $session;
>
> my %session = ();
> tie %session, 'Apache::Session::Postgres', $session, {
> DataSource=>'dbi:Pg:dbname=sessions',
> UserName=>'postgres',
> Password=>'password',
> Commit=>1
> };
> my $cookie = "SESSION_ID=".%session->{_session_id}.";
> domain=.dom.com; path=/;";
> $r->header_out("Set-Cookie"=>$cookie ) if ! $session;
> $r->pnotes('SESSION_ID', %session->{_session_id});
> $r->pnotes('AUTH_LEVEL', %session->{auth_level} || 0
> );
> $log->error("Session: ".%session->{_session_id});
> untie(%session);
> undef %session;
> $log->error("Session: End Transaction");
> return DECLINED;
> }
>
>
Re: [OT] Availability of Jobs -- was Re: [SOLICITATION] Programmer available for contracting..
On Thu, 11 Jan 2001, Stas Bekman wrote: > On Wed, 10 Jan 2001, mehryar wrote: > > > > > Im not sure about the contract positions but this is traditionally the > > time of the year when people decide its time for a change, its endemic to > > all other types of industries not just the software industry. > > And to alleviate your paranoia a little, a report I read last month said > > software jobs were actually on the increase, rivalling the ever > > hungry system administration job market. > > Not really, if you didn't know about http://fuckedcompany.com/ you should > check it out. (It has nothing to do with XXX). While you are on the spot > especially look at how many layoffs reported per day lately!!! Then check > the NASDAQ and you will get even more ideas about what's going on. > > It doesn't mean that we are in trouble, since mod_perl programmer are > scarce but the general trade is that many startups go busted. It's hard to believe how far off topic this is, but I'll reply in kind since the official list policeman has taken this path himself :) The most important thing I learned from fuckedcompany.com is the term "Javateer". -jwb
Re: Apache::Session::MySQL question regarding lenght of _session_id
On Mon, 18 Dec 2000, Andreas Marienborg wrote: > I just can't seem to find any info on how to specify that Apache::Session > should create session_id's that are shorter than 32 hex chars? could > someone point me in the right direction?? You can use the argument 'IDLength' when using Apache::Session::Generate::MD5 (the default), or you can replace that class with your own class to generate the IDs you desire. See the obscure Apache::Session::Generate::MD5 perldoc. -jwb
Re: mod_perl advocacy project resurrection
On Wed, 6 Dec 2000, Matt Sergeant wrote: > On Tue, 5 Dec 2000, Jeffrey W. Baker wrote: > > > With J2EE you get the complete illusion that you are doing txns across as > > many data sources on as many systems and vendors as you want, but behind > > the illusion there is the nonzero risk that the data is inconsistent. In > > a real transactional system, you can never have inconsistent data. > > This thread is suffering from a severe lack of technical information. Can > you go into more technical detail on what that 0.01% is (and is caused > by)? Yup. Machine A is controlling a transaction across Machine X and Machine Y. A modifies a row in X and adds a row to Y. A commits X, which succeeds. A commits Y, which fails. Now what? A cannot guarantee a recovery on machine X because there might already be other transactions in flight on that record in that database. A cannot just try to put the record back the way it used to be, because now the commit might fail on X. The data is inconsistent. The only thing that Machine A can do now is send an email to the DBA explaining what happened and what was supposed to happen. "Fucking Hell" says the DBA, under his breath. -jwb - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
On Tue, 5 Dec 2000, brian moseley wrote: > On Tue, 5 Dec 2000, Perrin Harkins wrote: > > > > Transaction support for your business logic is easy in J2EE. It's not > > > clear how you do this in Perl? > > > > Use an RDBMS. > > what about transactions that span data sources? yes, this > does happen. Yeah, it *seems* to happen, but it doesn't actually. Any vendor who tells you he can do real transactions across data sources is a liar, or using a new and improved definition of transaction. You can do it %99.99 of the time but that last %.01 is the bitch. With J2EE you get the complete illusion that you are doing txns across as many data sources on as many systems and vendors as you want, but behind the illusion there is the nonzero risk that the data is inconsistent. In a real transactional system, you can never have inconsistent data. Lesson: you can sell most people an illusion :) -jwb - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mod_perl advocacy project resurrection
On Tue, 5 Dec 2000, Perrin Harkins wrote: > Brian, you've been taking a beating on this thread. I don't want to add > to it, but you did raise a couple of interesting questions in this post. > > > the availability of application server products in the java world is > > another example. go look at enhydra enterprise > > (http://www.enhydra.org/software/enhydraEnterprise/) and tell me that > > something like that exists in the perl world. > > Personally, I'm kind of pleased that nothing like that exists in the perl > world. It looks like a recipe for a slow site to me - complexity for the > sake of complexity. But I've been burned by Java "application servers" > before so I may be a bit prejudiced against Enhydra. I think the part of > server-side Java that has the most value is the basic servlet API. > Personally, I find it pretty easy to replicate those services in mod_perl > without doing any additional coding, but I know you believe it's still too > difficult for newbies, and you may be right. The Big Thing for a serious project is providing a lot of services. If you look at Weblogic server, you get all database, sessions, message queuing, directory access, blah blah blah for free. Basically, the programmer lives in a little cocoon where a truckload of services are available and he only has to worry about his code. Contrast that with a mod_perl server. Out of the box, the only thing you get is a request object. I love that, and that's why if I want to add a little widget to my intranet, of course I do it in mod_perl and it takes me 15 minutes. But growing is nearly impossible. Adding data access, session management, and the like require work on the part of the programmer, and I think this list can testify that a lot of people don't do it properly. I haven't looked at AO or AxKit, but if I can untar either one of them and just get to work, that will rule. (An aside: you can literally just unzip weblogic.zip and start it. It is extremely simple, and it hasn't been "slow" in years.) > Part of the problem then is that perl is all things to all people. This > thread has already covered both the "it's harder than PHP", which is true, > and the "it's not as polished as Java", wich is also true. Some projects, > like Embperl and Apache::ASP, have gone a long way to make the barriers to > entry lower for the PHP types. There has also been a lot of effort to > make more polished web pages and documentation for some mod_perl projects > lately, Mason and AxKit being cases in point. I doubt it will ever > compete with Java in this regard though, since no single mod_perl project > is likely to get the same level of promotion that a WebLogic can muster. > The mod_perl message will probably always be about choice, flexibility, > and source code. > > > you don't have to spend time re-integrating Apache::Session and > > Apache::DBI and Apache::WipeMyAss with each new project. > > I think Apache::WipeMyAss auto-configures as of 0.3. But seriously, do > people have that much trouble using these defacto standard modules? > Maybe they need some more work in certain areas if they don't function > correctly "out of the box" for most people. There are a whole lot of people who just can't understand how to install Apache::Session. They shouldn't need to. -jwb - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache::Session Questions
On Thu, 23 Nov 2000 [EMAIL PROTECTED] wrote: > I installed Apache::Session and am employing embed perl to do some simple > session management. Apache restarts fine as of now. > However, when I try using %mdat or %udat I get this error message: > > [57250]ERR: 24: Line 17: Error in Perl code: No space left on device at > /usr/local/lib/perl5/site_perl/5.005/Apache/Session/Lock/Semaphore.pm line > 92. > > how much space does the Semaphore locking mechanism require? Is there any > way around using the Semaphore argument in setting up Apache::Session to > work with embed perl? The message doesn't refer to a disk device. For some reason, the code could not create a semaphore block, and the system returned ENOSPC. See the semget(2) manual page. The solution is to ensure that semaphores are enabled and available on your platform. On various different unixes, this may mean mounting a symbolic file system, setting system boot parameters, or changing some permissions. As for your other questions, I don't know enough about EmbPerl to answer them. Regards, Jeffrey Baker - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Apache::Session - kludgy workaround?
On Wed, 4 Oct 2000, Jerrad Pierce wrote: > Reading the directions ;-) > > Apache::Session doesn't do any deep checking, if a top level doesn't value > doesn't change > it may not detect the change. > > This is why your workaround works... > > The offically recommend workaround (I believe) is to keep a timestamp as a > top level value in the hash... You may also force saving of a session via: tied(%session)->make_modified(); There is a complete object interface to Apache::Session but you have to read Session.pm to explore it. -jwb
Announce: Apache::Session 1.53
Apache::Session 1.53 has been released. Fixed in this release: * Three bugs in the file handling code found by Erik Rantapaa and Bart Shaefer. * A possible security vulnerability involving bogus session IDs like '../../../../../etc/passwd'. Don't worry, I wasn't able to actually think of an exploit, but I put in sanity checks on the session IDs just in case. Have fun, Jeffrey Baker
Re: [OT] [JOB] mod_perl coders welcome at Quios
On Thu, 10 Aug 2000, Tom Mornini wrote: > I've recently been promoted to Manager, Engineering at Quios. Quios has an > mod_perl/Oracle web site that servers over 1 million page/views per day, > and is growing fast. > > Quios is an international wireless messaging company. Our site is > www.quios.com. > > We're looking for really good senior engineers who can take a project by > the horns and deliver finished product. Full time employment is our goal, > not contracting. > > Depending on your skills, projects will be Registry, handler, library > modules, and some interesting perl but not mod_perl projects as well. > > Quios engineering is located in San Francisco, California. Relocation and > H1B Visas are OK. I looked hard at Quios when I was looking for a new job. They have a lot of projects there that will interest readers of this list. If you are a hacker hunting jobs, you would do well to look into Quios. Regards, Jeffrey Baker
RE: was Re: template kit..... - now session handling
On Mon, 31 Jul 2000, brian moseley wrote: > On Mon, 31 Jul 2000, Perrin Harkins wrote: > > > Since it isn't really tied to HTTP or sessions, that > > would be kind of a misnomer as well. Jeff already > > suggested Persistent::Hash at once point, but changing > > namespace on CPAN always confuses some people. There > > are still people who get confused about the original > > Apache::Session module that was replaced by Jeff's. > > people who get confused by name changes should not be > catered to. I wasn't following this thread, because the subject was "template kit." Now I shall reply all in one shot. 1) A cookie/token management module will *not* be built into Apache::Session. The functionality is orthogonal. (i.e. Gerald is right). 2) The name change should happen. However, there is already a Persistent:: set of classes, that is somewhat similar to Apache::Session. For example, it implements LDAP, MySQL, Oracle, Sybase, mSQL, and File storage. These classes use all object calls e.g. $persistent->add_attribute(). So the chief difference seems to be the flexibility of the tied interface of Apache::Session (also mine is faster :) So how does Persistent::TiedHash sound? 3) The Apache::Session name whould be used for a module that actually manages the interaction between mod_perl and the browser. The only problem I can see is that this module would have to start out at 2.0 or something, to avoid confusing CPAN. ALternately, it could be called Apache::SessionManager instead. -jwb
Re: Lifetime session with Apache::Session module version 1.51
On Fri, 28 Jul 2000, Eddy Vernay wrote: > Hi, > > I have a problem with the Apache::Session module. > > Before, I was using the version 0.15 of this module. In this version, we can > use the SESSION_LIFETIME variable to define how long the session stays valid > after the last request to the server. > > I tried to update the Apache::Session module with the last version (1.51). > But I can't find the same variable, either anyone else which can do the same > thing. > > Is this fonction not supported anymore by the Apache::Session module? And > what must I do to use it if it still exists? The function no longer exists. Apache::Session does not pretend to manage the interaction between your web server and your clients, only your web server and your backing store. -jwb
Re: Templating system
On Thu, 27 Jul 2000, Matt Sergeant wrote: > On Thu, 27 Jul 2000, Darko Krizic wrote: > > > I want to write a new application using mod_perl but this time I want to > > completely divide the code from the HTML. Therefore I am seeking for a > > powerfull and fast templating system. > > > > Newly I did something with Enhydra (Java Servlets) and they have a pretty > > neat templating system: They use standard HTML and one uses the "id" > > attribute in HTML tags to access them and manipulate values/contents. For > > example: > > > > > > > > Name > > Count > > > > example name > > example count > > > > > > > > The program now can repeat the tr "singlerow" for each table row and insert > > it under the tr "resultheader". The values can be inserted into the tds > > "row_name" and "row_count". The main advantage is: The designer can generate > > HTML pages that can be viewed with a standard browser. > > > > Does anybody know something similar for Perl? > > No, but I was thinking of incorporating enhydra's XMLC technology into > AxKit. I'm not sure its a better method of working than XSLT or > XPathScript though, which allows you to be future looking (always > XML). But it could be kinda neat to do. Should be almost trivial with > HTML::Parser to generate perl out of that. Providing of course they don't > have some stupid patent on it (doubtful since its GPL'd). Has anybody looked at transformiix for doing these xslt transforms? It is an XSLT processor with an API. It requires expat. http://lxr.mozilla.org/mozilla/source/extensions/transformiix/docs/readme.html -jwb
Re: Templating system
On Thu, 27 Jul 2000, Paul J. Lucas wrote: > On Thu, 27 Jul 2000, Darko Krizic wrote: > > > I want to write a new application using mod_perl but this time I want to > > completely divide the code from the HTML. Therefore I am seeking for a > > powerfull and fast templating system. > > http://www.best.com/~pjl/software/html_tree/ > > It does precisely what you're asking. Hey, that's really nice. And once the template HTML files are parsed, I can just leave the $root_node in memory for future requests, right? ANd since the parser isn't validating, I can extend HTML with tags like , , and , right? Pant, pant. -jwb
[ANNOUNCE] Apache::Session 1.52
Apache::Session 1.52 has been uploaded to CPAN. The main change in this version is the inclusion of modules to work with Sybase, contributed by Chris Winters, and a smattering of bugfixes. There is a memory leak if you use a persistent database handle with Apache::Session. The memory leak is in DBI, and I haven't had a chance to fix it yet. You can minimize the impact of the leak by occassionally letting your Apache children die, or re-opening your database connections. Get the new Apache::Session here: http://www.perl.com/CPAN/modules/by-authors/Jeffrey_Baker/ -jwb
Re: Apache::Session and blessed references
On Wed, 31 May 2000, Dylan Weed wrote:
>
> I can't seem to get Apache::Session to save the blessedness of an object.
> Is this an oversight on my part, a limitation of the module, a limitation
> of the database, or an intentional design decision?
>
> Conceptually, it seems as though an objects blessing is stored in a
> different place in the Perl guts than its contents. Is the problem just
> that Apache::Session never saves this information to the database?
>
> Has anyone else had occasion to do this?
>
>
>
> An example in Perl:
>
> # %session is a hash tied to a DB with Apache::Session 1.51
>
> package main;
>
> my $dog_obj = { name => 'Fido', breed => 'Mutt' };
>
> bless ($dog_obj, 'Dog');
>
> $dog_obj->bark();
> $session{my_dog} = $dog_obj;
>
> # The following line dies with an error:
> # cannot call method bark on unblessed reference.
> $session{my_dog}->bark();
>
> package Dog;
>
> sub bark {
> my $self = shift;
> print "Woof! I'm $self->{name}";
> }
You know, I thought that there was a problem here when I first saw this
email, but today I simply cannot reproduce it. When I run the example
program, everything barks.
Can you still reproduce this problem, and, if so, could you please send me
a complete, working perl program as a demonstration?
Regards,
Jeffrey
Re: Apache::Session::MySQL problem
On Thu, 20 Jul 2000, Tatsuhiko Miyagawa wrote: > I'm using Apache::Session 1.51 + mysql 3.22.32 + > mod_perl 1.24 + Apache 1.3.11. They work well except > one problem. > > The problem is, if an acquired Session ID (from Cookie) > is not stored in the session database, Apache goes like > > > panic: POPSTACK > > Callback called exit. > > I know Apache::Session will die "Object does not exist > in the data store" when it can't restore a session from > database. So my script catch that exception with eval > block. > > But panic will happen. why ? Bug in Perl. Upgrade. -jwb
Re: ORA conference
On 15 Jul 2000, Randal L. Schwartz wrote: > > "Ask" == Ask Bjoern Hansen <[EMAIL PROTECTED]> writes: > > Ask> I'll bring my camera - > Ask> http://www.nikonusa.com/products/detaild1.cfm?id=286 - and will post > Ask> pictures if I don't get too bored carrying it around. (it's heavy). > > Pshaw! My coolpix 990 will CRUSH your D1 in a NO HOLDS BARRED title > match ... > > SUNDAY SUNDAY SUNDAY > > BE THERE! Boy you guys must be pissed about this, then: http://www.dpreview.com/articles/canond30/ :) As if Linux vs. BSD wasn't bad enough, now we can have Nikon vs. Canon! P.S. I'll destroy you all with the old school 35mm quality. ;) -jwb
Re: ORA conference
On Fri, 14 Jul 2000, Vivek Khera wrote: > > "MS" == Matt Sergeant <[EMAIL PROTECTED]> writes: > > > MS> Does anyone know if all the events will be in the program, or should I > MS> start making entries in my palm pilot? > > I started to do that, then realized that I don't have a palm pilot and > was actually writing on my palm. Most annoying, but effective, I > guess. > > Anyone comeing to town Sunday? I gotta find something to do Sunday > night... I'm coming down on Sunday. I'll be motorcycling, if anyone wants to join me for a ride from SF to Monterey. Cheers, Jeffrey
Re: Apache::session and Apache::DBI::Oracle headaches
On Tue, 11 Jul 2000, Chad Billigmeier wrote: > Having a bit of trouble getting apache::session to run with apache::DBI. Is > this due to the fact that Oracle wants AutoCommit on and Apache::DBI has it > off or is there some other magic that I am missing out on? Is anyone using > Apache::Session with Apache::DBI??? > > The error_log reports finding an existing DBI connection but no data is > written to the tables. Autocommit is off...I remember reading something > about Session::store() but can't find it anywhere. Can anyone help. I quote from the Apache::Session::Oracle perldoc: The special Apache::Session argument for this module is Commit. You MUST provide the Commit argument, which instructs this module to either commit the transaction when it is finished, or to simply do nothing. This feature is provided so that this module will not have adverse interactions with your local transaction policy, nor your local database handle caching policy. The argument is mandatory in order to make you think about this problem. If that isn't enough information, let us know. Your problem report is incomplete and confusing, so we will need a more clear picture before we can provide more help. Best Regards, Jeffrey Baker
Hope you didn't miss me too much
I got a three week vacation from technology as a wedding gift from myself. I'm back now, and I'll get around to answering many of the Apache::Session questions I recieved in the coming days. Cheers, Jeffrey
Re: [OT] [JOB] mod_perl and Apache developers wanted
On Thu, 15 Jun 2000, Shane Nay wrote: > Hehe, I was going to say I thought I saw some etoy.com action in Perrin's > headers, but looks like he spoke up for himself. The bottom line is that a lot > of companies have law departments that Do Bad Things. You just have to keep > them in check. (i.e. Get GPL clauses in your contracts!, it's _IMPORTANT_, I'm > doing this right now, and will see if it's okay with my lawyer to post the > wording for anyone to use.) Besides of course abiding by all your software licenses, I believe programmers working for Internet companies have another serious duty. That is to squarely refuse to assist in the filing of insipid patents. You can also have it written into your offer of employment that patent applications are excluded from your work duties. By doing so, the technical people who are behind the inventions can keep the Internet patent land grab from getting out of control. IMHO, naturally. Your philosophical mileage may vary. Jeffrey Baker
Re: [OT] [JOB] mod_perl and Apache developers wanted
On Thu, 15 Jun 2000, Bill Hilf wrote: > What we're about: > - > We are a strictly *nix software development shop and encourage and promote > the use and publication of Open Source software. Our Engineering staff > includes developers who contribute heavily to lists such as this, and have > numerous contributions throughout the Open Source and web development > communities. Our work environment is casual and fun - our focus is on > building great software, not if you're in the office at 8am. All the > other typical tech benefits apply: free sodas, concierge services, home > high-speed access, etc. We're located in Santa Monica, Calif., about five > minutes from the beach. You forgot the part about suing legitimate domain name holders, harrassing artists with little or no income, and trying to extend USA jurisdiction to the internet. While I'm sure the engineering department had no part in such things, I believe the readers of this list acare deeply about corporate culture and freedom on the Internet. Jeffrey Baker
Re: Apache::Session 1.52 problems
On Fri, 9 Jun 2000, Miah Gregory wrote: > Hi all, > > I'm just writing to ask if anyone else has had problems > with this version of the module? > > Thanks in advance. There is no such version as 1.52. You may be having problems with 1.51. There is a known problem with storing items in a newly-created session object. I intend to fix this Real Soon Now. Expect before next Thursday. -jwb
Re: Apache::Session
On Thu, 1 Jun 2000 [EMAIL PROTECTED] wrote: > In a message dated 6/1/2000 10:59:48 AM Eastern Daylight Time, > [EMAIL PROTECTED] writes: > > > Now, I am successfully able to run the script and generate sessionID and > > store that sessionID in MySQL database table.. But column 'a_session' is > > always empty!! Following is my code.. When I ran this code first time, I > > thought, I will have value of '$name' in column 'a_session' but I was > > wrong!! I mean I am in impression that, in MySQL datastore we can store > > all information about session for a particular sessionID. But it's not > > the case.. Whereas if I run the sample example which uses > > Apache::Session::File, I can see value of '$name' in the actual session > > file!!! So, Can somebody clear my doubts here?? > > > > Thanks in advance.. > > If you followed the perldocs, you also made a_session a BLOB. > You won't be able to see the contens of the BLOB doing a > simple select from a command line SQL interface. A BLOB is > binary data. > > Plus, it has three columns, not two as you say... > id varchar(16) > length int(11) > a_session blob Actually only two are needed. The length column can be omitted. -jwb
Re: Apache::Session and blessed references
On Wed, 31 May 2000, Dylan Weed wrote:
>
> I can't seem to get Apache::Session to save the blessedness of an object.
> Is this an oversight on my part, a limitation of the module, a limitation
> of the database, or an intentional design decision?
>
> Conceptually, it seems as though an objects blessing is stored in a
> different place in the Perl guts than its contents. Is the problem just
> that Apache::Session never saves this information to the database?
>
> Has anyone else had occasion to do this?
Well, that sucks a lot. This is actually a bug in Apache::Session. If it
was working properly, blessed references should be fine. Unfortunately,
the module doesn't seem to be saving hash entries that are added
immediately after creation. I will fix this tomorrow.
Also I will add a test for this case.
>
>
>
> An example in Perl:
>
> # %session is a hash tied to a DB with Apache::Session 1.51
>
> package main;
>
> my $dog_obj = { name => 'Fido', breed => 'Mutt' };
>
> bless ($dog_obj, 'Dog');
>
> $dog_obj->bark();
> $session{my_dog} = $dog_obj;
>
> # The following line dies with an error:
> # cannot call method bark on unblessed reference.
> $session{my_dog}->bark();
>
> package Dog;
>
> sub bark {
> my $self = shift;
> print "Woof! I'm $self->{name}";
> }
>
>
RE: [ANNOUNCE] Apache::Session 1.51
On Wed, 31 May 2000, James Xie wrote: > > Thanks. > > I have the storable module installed but I got the following error messages > when I try to run "make test". > > Do I need to create the sessions database manually? I don't see it when I > run the "mysqlshow" command. I have mySQL installed. The test suite is nonportable. You can safely ignore any database-related problems. Suggestions about making portable database test scripts are welcome. -jwb
RE: [ANNOUNCE] Apache::Session 1.51
On Wed, 31 May 2000, James Xie wrote: > > Which version of Storable module do I need for Session 1.51? > Storable-0.6.11 ? it's still under beta testing. Any version should work. -jwb
RE: Wierd problem with redirect
On Tue, 30 May 2000, Jerrad Pierce wrote: > I'm running into an odd redirect ptoblem myself, I'm issuing: > > HTTP/1.1 302 Moved Temporarily\n\r > Date: Tue 30 May 2000 18:18:07 GMT\n\r > Server: Apache/1.311\n\r > Set-Cookie: SESSION_ID=4177a0c9ae2b278decd6038901b28a2a; path=/; > expires=Thu, 1-Jan-70 00:20:00 GMT;\n\r > Location: /\n\r If you don't follow the HTTP specification, you can't expect the browser to do the right thing. "/" is not a valid URI for a Location. According to RFC 2616, the Location must be an absolute URI: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.30 In RFC 2396, an absolute URI is defined as: absoluteURI = scheme ":" ( hier_part | opaque_part ) So your method is not valid, and you deserve whatever the browser does to you. You should do this instead: Location: http://mysite.com/\n\r Regards, Jeffrey
Re: Modifying of Apache::Session File
On Wed, 31 May 2000, Differentiated Software Solutions Pvt. Ltd. wrote: > Hi, > > We've got an application where on initial login we're creating the session > file. > Subsequently, we want to add more hash values into this session file. > > Immediately after creation if we add values to the session file, these > values get stored. > After a few pages we tried to modify the existing session file, by > First, tie-ing the values to a session hash > Second, Modifying the session hash. > > At the point of modifying the session, the program just hangs waits > indefintely. > Can anybody help us out with this problem. You must have leaked some session objects, and now you are holding stale locks. It is a frequent problem. If you are using a global for the session object, don't do that. Also don't make a circular reference to the session object. -jwb
Re: patch for Apache::Session::Store::Postgres
On Mon, 29 May 2000, Michael Blakeley wrote:
> Patch for Apache::Session::Store::Postgres, from
> Apache-Session-1.51.tar.gz, to resolve problems with
>
> >prepare_cached(SELECT a_session FROM sessions WHERE id = ? FOR
> >UPDATE) statement handle DBI::st=HASH(0x369a2c) is still active
>
> after a transient error. The solution is to call sth->finish()
> whether the SELECT was successful or not.
>
> diff Store/Postgres.pm.orig Store/Postgres.pm
> 78a79,81
> ># success or failure, don't leave FOR UPDATE lying around
> > $self->{materialize_sth}->finish;
> >
> 83,84d85
> < $self->{materialize_sth}->finish;
> <
Hrmm, I'm not really an expert here. If I do a SELECT ... FOR UPDATE on a
row that doesn't exist, shouldn't that just do nothing?
To squash this warning, we could just as easily use the allow_active flag
in the prepare method.
-jwb
Re: Modified DBIStore.pm for Oracle
On Fri, 26 May 2000, Chetan Patil wrote: > Hello, > I have modified DBIStore.pm (in Apache-Session-1.03) to work with Oracle. > I am attaching the diff at the end of this email for anyone who is > interested. Thanks for the effort! > > I just found out that there is new version of Apache-Session (1.51) > available that shall work with Oracle out of the box. > > Oh well!! In case anyone cares, here is my setup > Apache-Session-1.03 > DBD-Oracle-1.03 > DBI-1.13 > Digest-MD5-2.09 > Storable-0.6.11 > > The "sessions" table setup is > > id char(16) > length int(11) > a_session BLOB > > Also, you would want to use > LongReadLen => '2147483647' > in the opts hash of example.perl (Apapche-Session-1.03). Doing so gives DBD::Oracle free reign to malloc(2**31), which is likely to be more memory than you really want to give to one process. Your sessions are not likely to be that large, either, so you should use something more sane like 2**16 or thereabouts. Best, Jeffrey
Re: Apache::Session::Pg & blob support?
On Sat, 27 May 2000, Gunther Birznieks wrote: > At 03:08 PM 5/26/00 -0400, Richard Dice wrote: > >Hello there... > > > >I was wondering, with the new Pg-specific support you've got going with > >Apache::Session, does it handle Pg blobs transparently? > > > >The regular limit on the size of a tuple in Pg is 8k, which can be a > >problem if I'm trying to put more than that into my Apache::Session > >tied hash. (Yes, I do that sometimes. It's a handy place to hide > >stuff, those sessions...) > > Well, they are handy at that. But on the other hand, I tend to question the > use of storing a LOT of data in sessions. > > At the point that the data reaches a critical mass, then it is likely that > the data is getting more crucial to the application. If the data is crucial > to the application, that also tends to mean that it would be best served > (ultimately) by having an appropriate data structure where the session ID > happens to be a key. While my persistent objects tend to be under 1K, I don't intend to enforce policy on users of Apache::Session. If we can remove a size limitation without introducing other problems, I say let's do it. -jwb > > eg I may make a file based session for just storing sundry things, but I > would rarely want to store a shopping cart for a web store inside a > session. A shopping cart is a data structure that has potential links to > other information such as inventory tables. Now, the cart should be tied to > the session id anyway, but whether the data should be stored as one big > blob is another issue. > > Another thing about huge sessions is that depending on your locking and > concurrency considerations, one big blob can become suboptimal for > performance if you are not careful. > > Anyway, I guess this is just a philosophical issue with me. I know others > like to store everything in their sessions. :) > > Later, > Gunther > > __ > Gunther Birznieks ([EMAIL PROTECTED]) > Extropia - The Web Technology Company > http://www.extropia.com/ > >
Re: [ANNOUNCE] Apache::Session 1.51
On Fri, 26 May 2000, Perrin Harkins wrote: > I know you were working on a BerkeleyDB storage module. Are you still > working on it, or did you throw up your hands in disgust over the > BerkeleyDB module? Although I don't have time right now, I could > eventually work on this if you aren't already doing it. I threw up my hands in disgust. BerkeleyDB.pm is truly repulsive. -jwb
Re: [ANNOUNCE] Apache::Session 1.51
On Fri, 26 May 2000, Perrin Harkins wrote: > On Fri, 26 May 2000, Jeffrey W. Baker wrote: > > I have released Apache::Session 1.51. The addition of the Oracle backing > > store took less time than expected. It is included and tested in this > > release. This is the only change from 1.50. > > > > http://www.cpan.org/modules/by-module/Apache/Apache-Session-1.51.tar.gz > > This new stuff looks really good. This module has come a long way in the > time I've been watching the list. > > A couple of notes on the Oracle storage module: > > - Using "FOR UPDATE" forces the transactional lock model. Is it possible > to make this optional? The other modes allow the use of a "enforce data > integrity only" locking style which is sometimes needed. I'm less worried > about people overwriting their own session data than I am about stale > locks, although I suppose Apache::DBI's cleanup handler should take care > of them. I assume that if people are using a transactional database, they are knowledgable about transactions. That's why I made the Commit argument mandatory for the Oracle and Postgres backing stores: it forces people to consider their transaction policy. > > - Oracle (the company) says not to use LONG anymore. They are trying to > move everything to CLOB/BLOB. I modified my Apache::Session::DBI to > support this, which mostly involved specifying "ora_type => ORA_BLOB" in > my bind variable parameters. Maybe we need and Oracle8 module, separate > from the standard one? By the way, BLOBs don't work with synonyms, so you > have to specify the schema name in the SQL when using them. That's lame. So, we would need to pass the schema name as an argument? Remind me again what's wrong with LONG? > I know you were working on a BerkeleyDB storage module. Are you still > working on it, or did you throw up your hands in disgust over the > BerkeleyDB module? Although I don't have time right now, I could > eventually work on this if you aren't already doing it. > > Finally, everybody loves benchmarks. Do you have any cool speed > comparisons between the various storage and locking options? I'm sure the > list would be very interested. Even better would be a little benhcmarking > script that people could use on their own systems to do comparisons. Maybe i'll whip something up that;s portable. For benchmarks that aren't portable, check the b/ directory in the distro. -jwb
[ANNOUNCE] Apache::Session 1.51
Greetings, I have released Apache::Session 1.51. The addition of the Oracle backing store took less time than expected. It is included and tested in this release. This is the only change from 1.50. http://www.cpan.org/modules/by-module/Apache/Apache-Session-1.51.tar.gz Please wait a few hours for the tarball to propogate. Best, Jeffrey
Re: Apache::Session::Pg & blob support?
On Fri, 26 May 2000, Richard Dice wrote: > Hello there... > > I was wondering, with the new Pg-specific support you've got going with > Apache::Session, does it handle Pg blobs transparently? > > The regular limit on the size of a tuple in Pg is 8k, which can be a > problem if I'm trying to put more than that into my Apache::Session > tied hash. (Yes, I do that sometimes. It's a handy place to hide > stuff, those sessions...) > > If that's not part of the new release, probably me and/or another guy > I'm working with is going to code that up. We talked about it a few > days ago but wanted to wait until the new release to see what the status > of this would be. Yes it would be great to break the 8K (actually slightly less) limit, if it doesn't hamper performance too much. I read the docs on the Postgres web site, but I didn't find anything interesting about blob support. I would welcome a patch. Are you trying to stuff GIFs into the session hash? ;) Regards, Jeffrey
Re: [ANNOUNCE] Apache::Session 1.50 has been released
On Fri, 26 May 2000, William Deegan wrote: > Does this new release mean I connot use Oracle as the backing store? Were you using it before? If so, it was purely accidental that it worked. I am working on an Oracle backing store right now, which i might even finish today, but I didn't include it in 1.50 because I didn't consider feature parity with 1.03. Doesn't 1.03 fail with truncated longs? If not, can you send me a description of your table? -jwb > > -Bill > > > I am pleased to announce that Apache::Session version 1.50 has been > > released. This is a major update from the previous version. > > > > Notable updates include: > > > > *Support for Postgres as a backing store > > *Support for Berkeley DB as a backing store > > *Support for serialization into ASCII instead of binary data > > *Pluggable ID generation policies and serialization schemes > > *Database backing stores can now use existing database connections > > *Apache::Session::Flex lets you choose modules at runtime > > *Full transactional consistency is now available with all backing stores > > > > Subtle incompatibilities: > > > > *Default IDs are now 32 characters instead of 16 > > *Apache::Session::DBI is gone, in favor of specific MySQL and Postgres > > modules. > > *Semaphores are no longer used by default on any platform. > > > > You can get the new module at > > http://www.cpan.org/modules/by-module/Apache/Apache-Session-1.50.tar.gz > > > > Best, > > Jeffrey > >
[ANNOUNCE] Apache::Session 1.50 has been released
Greetings, I am pleased to announce that Apache::Session version 1.50 has been released. This is a major update from the previous version. Notable updates include: *Support for Postgres as a backing store *Support for Berkeley DB as a backing store *Support for serialization into ASCII instead of binary data *Pluggable ID generation policies and serialization schemes *Database backing stores can now use existing database connections *Apache::Session::Flex lets you choose modules at runtime *Full transactional consistency is now available with all backing stores Subtle incompatibilities: *Default IDs are now 32 characters instead of 16 *Apache::Session::DBI is gone, in favor of specific MySQL and Postgres modules. *Semaphores are no longer used by default on any platform. You can get the new module at http://www.cpan.org/modules/by-module/Apache/Apache-Session-1.50.tar.gz Best, Jeffrey
Re: Form generation libraries
On Thu, 25 May 2000, Peter Haworth wrote:
> On 24-May-00 at 18:50, Jeffrey W. Baker ([EMAIL PROTECTED]) wrote:
> > It's C with function pointers as struct members.
>
> That seems a little excessive to me spacewise, but I guess it means you can
> keep the functions static, and not confuse users with differently named
> functions to do the same thing with different types of input.
Yes exactly. For example, each type can share the addAttr, getAttr,
setAttr, and delAttr methods, and the TextInput, CheckBoxInput, and
RadioInput could all share the same render method.
> It's just that you said you were adding at the list head for performance. I
> can't see the need for a doubly linked list if you don't have a pointer to the
> tail.
It will be handy when implementing the delAttr method.
> Not sorting still gets my vote. There are too any cases where you
> can't sort on just the value or just the label.
Well as I said if the programmer doesn't want to sort anything, then they
shouldn't call the method. I don't see anything wrong with adding a
capability that some people might not use.
>
> Anyway, I'd still like to see the code. In the meantime, HTML::StickyForm will
> probably start off in pure perl. The internals can always be rewritten to use
> your library at some point in the future.
I attached the files common.c and hfTextInput.c. The former contains the
attribute list manipulation routines (and should be renamed attrList.c),
and the latter is the partial implementation of the standard textbox
input. The render() method in hfTextInput could be shared by the checkbox
and radio types without modification.
Cheers,
Jeffrey
extern void addAttr(void*, char*, char*);
extern void destroyAttrs(attrList *);
#ifndef HTMLFORMS_H
#define HTMLFORMS_H
/*
* This header defines the public interface to the htmlforms library.
* Only the data structures and functions declared here are for public
* consumption. Poking around with stuff declared elsewhere is a no-no.
*/
typedef struct hfTextInput hfTextInput;
typedef struct attrList attrList;
struct attrList {
attrList *next;
attrList *prev;
char *name;
char *value;
};
struct hfTextInput
{
attrList *attrs;
void (*addAttr)();
char* (*render)();
void (*destroy)();
};
extern hfTextInput * hfTextInputNew();
#endif /* HTMLFORMS_H */
#include
#include
#include
#include "htmlforms.h"
#include "common.h"
typedef struct hfElement hfElement;
struct hfElement
{
attrList *attrs;
};
static attrList * newAttrList (char *, char *);
static void destroyAttrList (attrList *);
void addAttr (void *el, char *name, char *value)
{
attrList *cur, *new;
hfElement *myEl = (hfElement *)el;
new = newAttrList(name, value);
if (myEl->attrs == NULL)
myEl->attrs = new;
else
{
cur = myEl->attrs;
while (cur->next != NULL)
cur = cur->next;
new->prev = cur;
cur->next = new;
}
}
void destroyAttrs (attrList *list)
{
attrList *next;
while (list != NULL)
{
next = list->next;
destroyAttrList(list);
list = next;
}
}
static void destroyAttrList (attrList *list)
{
free(list->name);
free(list->value);
free(list);
}
static attrList* newAttrList (char *name, char *value)
{
attrList *new;
new = malloc(sizeof(attrList));
if (new == NULL)
abort();
new->next = NULL;
new->prev = NULL;
new->name = malloc(strlen(name) + 1);
if (new->name == NULL)
abort();
strcpy(new->name, name);
if (value != NULL)
{
new->value = malloc(strlen(value) + 1);
if (new->value == NULL)
abort();
strcpy(new->value, value);
}
return new;
}
#include "htmlforms.h"
#include "common.h"
#include
#include
extern hfTextInput * hfTextInputNew ();
static char * hfTextInputRender (hfTextInput *);
static void hfTextInputDestroy (hfTextInput *);
hfTextInput * hfTextInputNew ()
{
hfTextInput *new;
new = malloc(sizeof(hfTextInput));
if (new == NULL)
abort();
new->attrs = NULL;
new->addAttr = &addAttr;
new->render = &hfTextInputRender;
new->destroy = &hfTextInputDestroy;
return new;
}
char * hfTextInputRender (hfTextInput *self)
{
attrList *cur;
char *out;
int bytes;
/* \0 */
bytes = 8;
/* Count the bytes needed for each attr/value pair, including spaces */
cur = self->attrs;
while (cur != NULL)
{
bytes++; /* for the leading space */
Re: Bugs 5.6.0 modperl use?
On Wed, 24 May 2000, John M Vinopal wrote: > > Apache 1.3.12 > modperl 1.24 > perl 5.6.0 > > CGI::Carp preloaded. > DBI preloaded. > > [Wed May 24 19:58:28 2000] [error] PerlRun: `Bizarre copy of HASH in aassign > at /usr5/perl/lib/5.6.0/Carp/Heavy.pm line 79. > > Prototype mismatch: sub Apache::ROOT::cgi_2dbin::adtaker::get_username::SQL_INTEGER >vs () at /usr5/perl/lib/5.6.0/Exporter.pm line 57. > at /usr5/caps_prod/scripts/adtaker/get_username line 6 > > where SQL_INTEGER is imported via > use DBI qw(SQL_INTEGER); > > Anyone else seen these? Is anyone else using Perl 5.6.0? -jwb
Re: Form generation libraries
On Wed, 24 May 2000, Peter Haworth wrote:
> Jeffrey W. Baker wrote:
> > On Wed, 24 May 2000, Peter Haworth wrote:
> > > Jeffrey W. Baker wrote:
> > > > myInput = hfTextInputNew();
> > > > myInput->addAttr(myInput, "name", "first_name");
> > > > myInput->addAttr(myInput, "value", "Jeffrey");
> > > > printf("%s\n", myInput->render(myInput));
> > > > myInput->destroy(myInput);
> > > >
> > > > I would expect a similar interface with more methods for a select box,
> > > > e.g. mySelect->addOption(mySelect, myOption), and myOption->select.
>
> Is this C or C++? If C, do you have a member for each function in the struct,
> and if it's C++, why are you passing myInput twice? Or maybe you just got
> carried away with your example.
It's C with function pointers as struct members.
>
> > > Where do you store those attributes before you do the rendering? If you
> > > tie yourself to Apache, you could use tables. If you tie yourself to perl,
> > > you can use hashes. Otherwise you have to do your own hashes. Blech,
> > > especially if you then use the library with Apache and/or perl - wasted
> > > effort.
> >
> > Actually, there is another way, and that is to simply build a linked list
> > of attributes. It doesn't matter what order you put the attributes in, so
> > I just add them to the head of the list for performance. Adding to the
> > head of a list is faster than hashing anyway. If you use the
> > setAttr(self *, char *, char *) method, the list has to be scanned, but is
> > is likely to be so short as to not matter.
>
> OK, that seems sensible. There's no reason to go overboard to get more
> hash-like semantics, when you'll generally just be stuffing things in, then
> reading them all out.
Exactly. The mainstream use case is to add things and then render. The
capability to remove and change things exists, but doesn't need to be as
streamlined.
> > The other advantage here is storage space. An attribute in this
> > implementation takes up only 4*sizeof(void *) + strlen(name) +
> > strlen(value) + 2.
>
> Is it a doubly linked list, or are you storing something other than name,
> value, next?
Doubly-linked. You aren't sweating those extra 32 bits are you? ;)
>
> > > Bear in mind that it's nice to be able to support arbitrary attributes for
> > > things like onMouseClick and the like, horrible though they are. This
> > > means that you can't just define structs with members dedicated to
> > > specific attributes.
> >
> > Done. The same approach is also used for adding options to a select box,
> > although a select box will have an additional sort() method.
>
> Well, personally, I'd have sorted my options before setting them up. Otherwise
> you need unnecessarily complicated comparison functions to keep your "Please
> select something" option at the top. ALthough, if it works that way, adding
> options to a select has to add to the tail of the list, or you'd have to add
> your options in reverse order.
If the options are sorted before adding, then you just wouldn't call the
sort() method. Or maybe it would be sortByValue() and
sortByLabel(). That sounds more flexible.
-jwb
Re: Form generation libraries
On Wed, 24 May 2000, Peter Haworth wrote:
> Jeffrey W. Baker wrote:
> > I have read all of the messages in regarding the zygotic
> > HTML::Forms/FormGen project, and I like the idea. However, I hope that
> > the inplementation of such a beast isn't in Perl. To ensure that a
> > quality product results, I propose that this library be written in C, and
> > also in an object-oriented fashion.
> >
> > What I propose is an object interface to the various form input types, as
> > well as some higher level functionality that encapsulated what people
> > frequently do with HTML forms. For example, I would expect the C
> > interface to look something like this:
> >
> > myInput = hfTextInputNew();
> > myInput->addAttr(myInput, "name", "first_name");
> > myInput->addAttr(myInput, "value", "Jeffrey");
> > printf("%s\n", myInput->render(myInput));
> > myInput->destroy(myInput);
> >
> > I would expect a similar interface with more methods for a select box,
> > e.g. mySelect->addOption(mySelect, myOption), and myOption->select.
>
> Where do you store those attributes before you do the rendering? If you tie
> yourself to Apache, you could use tables. If you tie yourself to perl, you can
> use hashes. Otherwise you have to do your own hashes. Blech, especially if you
> then use the library with Apache and/or perl - wasted effort.
Actually, there is another way, and that is to simply build a linked list
of attributes. It doesn't matter what order you put the attributes in, so
I just add them to the head of the list for performance. Adding to the
head of a list is faster than hashing anyway. If you use the
setAttr(self *, char *, char *) method, the list has to be scanned, but is
is likely to be so short as to not matter.
The other advantage here is storage space. An attribute in this
implementation takes up only 4*sizeof(void *) + strlen(name) +
strlen(value) + 2. On 32-bit architectures, the attribute
name="myfield" only requires 29 bytes. Only 45 bytes are required on
64-bit architectures. Compare with Perl, where $hash{name} = 'myfield' is
costing several kilobytes at runtime.
> Bear in mind that it's nice to be able to support arbitrary attributes for
> things like onMouseClick and the like, horrible though they are. This means
> that you can't just define structs with members dedicated to specific
> attributes.
Done. The same approach is also used for adding options to a select box,
although a select box will have an additional sort() method.
-jwb
Re: Cookies
On Tue, 23 May 2000, Jim Serio wrote:
> Like I said, the cookie is being set, but I can't read the cookie.
> Apache::Cookie->fetch('cookie_name'); doesn't work.
>
> >this is a fixup handler? you shouldn't be sending the complete http
> >header there. you should use $r->headers_out like you did in your
> >original example. and, use telnet to see what your module is actually
> >sending, or a log handler that dumps $r->as_string, or Apache::DumpHeaders
> >(on cpan).
>
>
> This brings up a not-so-mod_perl question. Is there a way to telnet
> to name-based virtual hosts? Can I spoof the GET request?
telnet www.thesite.com 80
Trying xxx.xxx.xxx.xxx...
Connected to www.thesite.com.
Escape character is '^]'.
GET / HTTP/1.1
Host: www.virtualhost.com
HTTP/1.1 200 OK
Server: blah blah blah blah
...
Cheers,
Jeffrey
Form generation libraries
I have read all of the messages in regarding the zygotic
HTML::Forms/FormGen project, and I like the idea. However, I hope that
the inplementation of such a beast isn't in Perl. To ensure that a
quality product results, I propose that this library be written in C, and
also in an object-oriented fashion.
What I propose is an object interface to the various form input types, as
well as some higher level functionality that encapsulated what people
frequently do with HTML forms. For example, I would expect the C
interface to look something like this:
myInput = hfTextInputNew();
myInput->addAttr(myInput, "name", "first_name");
myInput->addAttr(myInput, "value", "Jeffrey");
printf("%s\n", myInput->render(myInput));
myInput->destroy(myInput);
I would expect a similar interface with more methods for a select box,
e.g. mySelect->addOption(mySelect, myOption), and myOption->select.
The Perl wrapper around this library is pretty obvious, and can use the
object-oriented approach also. We can build upon that with an
enhanced-for-mod_perl interface.
I expect that a C implementation will be ideal from the standpoint of
speed and also memory. I have taken the liberty of implementing the
neccessary code for the text input type, and the object code is a whopping
2116 bytes, which is mostly base class logic that won't be duplicated for
the other types. The implementation is also quite fast, rendering 10
simple text inputs to /dev/null in .78 seconds, without optimizations.
If people think this is the way to go, I will write up a Makefile and
release the code.
-jwb
Re: [newbie] Passing Session Object Twixt Handlers
On Mon, 22 May 2000, Perrin Harkins wrote: > On Mon, 22 May 2000 [EMAIL PROTECTED] wrote: > > It seems the Apache::Session::DBI isn't actually changing anything > > in the database, since next time I tie the session the only thing > > it has is the _session_id I tied it with in the first place. > > Keep in mind that Apache::Session only writes to the database when the > object is destroyed. Make sure it is really going out of scope. Almost. Apache::Session will commit to the backing store when the object goes out of scope, or when the programmer calls the save() method. tied(%session)->save; Cheers, Jeffrey
Re: [Re: Questions about Apache::Session]
On Tue, 23 May 2000, Michael Schout wrote:
> On Sun, Jun 29, 2036 at 12:21:26AM +, Edgardo Szulsztein wrote:
> > Hi again
> >
> > It worked great. Thanks for the help!
> >
> > Now, I would like to make it work with the postgresql database server. How
> > could I do it (I don't like the list, but I couldn't find this information in
> > the documentation).
>
> One of the problems I ran into when doing this was that Apache::Session uses
> Storable to freeze the session data before storing it in the database, put
> PostgreSQL does not like binary data in TEXT fields. So out of the box, it
> doesnt seem that you can use Apache::Session::DBI with postgresql.
>
> However, its very simple to get around this. I just created my own
> Apache::Session::UUDBI and Apache::Session::UUDBIStore modules (by copying the
> source for Apache::Session::DBI and Apache::Session::DBIStore). I then
> modified it so that every time it wrote the session data it called pack("u*",
> $data) to uuencode the session data. And everywhere it retrieved the session
> data it calls unpack("u*" $data) so that it reverses the operation. This
> results in storing the session data in the db in uuencoded format (text-only)
> and makes postgresql happy.
>
> Anyway, thats how I got around it. I'm sure there are several others.
>
> If you would be interested in my Apache::Session::UUDBI modules, send me an
> email and I will send you (or anyone else who might be interested) a copy of
> it.
That's precisely the right solution. The forthcoming Apache::Session 1.50
is slightly redisigned so that you can plug in the serialization scheme of
your choice, just as you can currently swap out the backing stores. The
codebase currently consists of the regular Storable, Storable wrapped with
MIME::Base64, and Storable wrapped with pack/unpack.
Are there other serialization schemes that need to be considered? I need
to test this stuff with a running Postgres, but other than that the code
is ready to be shipped.
-jwb
Re: RFC: Apache::Request::Forms (or something similar)
On Thu, 18 May 2000, brian moseley wrote:
> On Thu, 18 May 2000, Autarch wrote:
>
> > C seems like serious overkill for something to simply
> > generate plain text output. How slow is making a string
> > in perl compared to doing it in C? I can't imagine
> > there's to much of a difference.
>
> pretty slow if you build a string using .= instead of using
> smarter methods, like pushing strings onto an array and then
> joining it.
You tried to sell me that when I was at CP, and I didn't buy it then
either. This is a benchmark of .= versus join. 50 20-byte strings
are joined:
Concat: 2 wallclock secs ( 1.34 usr + 0.27 sys = 1.61 CPU)
Join: 4 wallclock secs ( 3.63 usr + 0.19 sys = 3.82 CPU)
.= concatenation is way faster. Also, building a 50-element array in
Perl takes up vastly more memory than building a 1000-byte string.
The string and the Perl process together require an RSS of 11MB, while the
array and the Perl process eat an RSS of 51MB.
Here is the benchmark program used:
my $iter = shift;
sub concat {
my $this;
for (my $i = 0; $i < $iter; $i++) {
$this .= 'A'x20;
}
}
sub arrayjoin {
my @this;
for (my $i = 0; $i < $iter; $i++) {
push(@this, 'A'x20);
}
join('', @this);
}
timethese(1, { 'Concat' => \&concat, 'Join' => \&arrayjoin });
The system was an Intel Pentium III 500 MHz with 128 MB of RAM and Linux
2.2.15. Swap was turned off.
-jwb
