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://wwwtohubohunet/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 '/table'. 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: 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
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: 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
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
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 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, verbose 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
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, 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
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 trtd$row-[0]/tdtd$row-[1]/td/tr\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: 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: 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: 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
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: 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
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: 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: 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
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)
yak yak
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;
}
yak yak
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:
[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: 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.mumble 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: 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.mumble 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: 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. Location ~ ^/$ SetHandler perl-script PerlHandler Slash::Host::slashcode::rootHandler /Location 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, LocationMatch is preferred over Location ~. 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: 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: 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.
[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: [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
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
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: 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
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: 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: [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, 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: 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: 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: 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: table id="results" tr id="resultheader" thName/th thCount/th /tr tr id="singlerow td id="row_name"example name/td td id="row_count"example count/td /tr /table 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
[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: 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: 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: 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 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: 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: 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: [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: [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: 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/
[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: 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.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
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 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 stdlib.h
#include malloc.h
#include string.h
#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 malloc.h
#include string.h
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;
/* INPUT\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 */
bytes += strlen(cur-name);
if (cur-value != NULL)
bytes += (3 /* ="" */ + strlen(cur-value));
cur = cur-nex
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: 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: [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: [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: 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
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
O'Reilly Con 2000 Rooms and Travel
I just registered for this year's O'Reilly Open Source Conference. I reserved a double occupancy room, even though I haven't planned to go with anyone else. If someone on this list is going and doesn't have a room, please email me and we can share. I reserved a non-smoking room in the Doubletree. Also I will be getting to Monterey by motorcycle from San Francisco. I'd love to ride with anyone from the SF Bay Area. Mail me. -jwb
Re: database efficiency
On Mon, 15 May 2000, Jay Jacobs wrote: I've been reading over the guide on "Efficient Work with Databases under mod_perl" and there's one thing I don't quite grok about it. Let's say I have a site that goes through select statements like water. If I were to cache the statement handler (as described in the guide), how does the database (database dependant) handle a bunch of dangling statement handlers? Will the database process size grow a ton? I'm not sure if I'm hitting what I wanted to ask, but hopefully I'm close enough. Every statement handle that you leave open will consume resources on the database server, and also on the client side. These resources are presumed to be more plentiful than the resources (CPU time and network packets) needed to frequently setup and teardown statement handles. -jwb
Re: database efficiency
On Mon, 15 May 2000, Ken Y. Clark wrote: On Mon, 15 May 2000, Jeffrey W. Baker wrote: On Mon, 15 May 2000, Jay Jacobs wrote: I've been reading over the guide on "Efficient Work with Databases under mod_perl" and there's one thing I don't quite grok about it. Let's say I have a site that goes through select statements like water. If I were to cache the statement handler (as described in the guide), how does the database (database dependant) handle a bunch of dangling statement handlers? Will the database process size grow a ton? I'm not sure if I'm hitting what I wanted to ask, but hopefully I'm close enough. Every statement handle that you leave open will consume resources on the database server, and also on the client side. These resources are presumed to be more plentiful than the resources (CPU time and network packets) needed to frequently setup and teardown statement handles. if this behavior is unacceptable, i believe you can use the finish method: finish $rc = $sth-finish; Indicates that no more data will be fetched from this statement handle before it is either executed again or destroyed. It is rarely needed but can sometimes be helpful in very specific situations in order to allow the server to free up resources currently being held (such as sort buffers). (from perldoc DBI) That's true, and the RDBMS would be free to release any buffers associated with unfetched rows in that case. However, you are still consuming server-side resources with every handle that remains open. At the very least, you are consuming memory on the order of sizeof(struct statement) or whatever. -jwb
Re: database efficiency
On Mon, 15 May 2000, Autarch wrote:
On Mon, 15 May 2000, Jay Jacobs wrote:
mod_perl" and there's one thing I don't quite grok about it. Let's say I
have a site that goes through select statements like water. If I were to
cache the statement handler (as described in the guide), how does the
database (database dependant) handle a bunch of dangling statement
handlers? Will the database process size grow a ton? I'm not sure if I'm
hitting what I wanted to ask, but hopefully I'm close enough.
Are you talking about the part that says you should use prepare_cached
vs. prepare?
If so, this doesn't do anything under most DBD modules, AFAIK. Under
Oracle, it causes Oracle to hold the statement handle (an Oracle
cursor)in cache after it generates the execution plan. If you open too
many of these eventually Oracle complains (I think you can close them by
wiping out $dbh-{CachedKids} which deletes the statement handles which
causes them to go through their DESTROY). The oracle error you get is
something like 'Too many open cursors' I think.
Actually, the two things you mention are different concepts. Yes, Oracle
does have a cache where it keeps most-recently-used execution plans. If
you make proper use of bound parameters in your SQL, you can exploit this
execution plan cache.
A statement handle is a handle that is associated with one of those
execution plans. Many handles may be associated with the same SQL
statement. You can bind parameters to the handle, execute it, and fetch
rows from it. There are resources associated with the handle, such as the
bound parameters and some state information. These are the resources that
are consumed if you agressively accumulate open statement handles on the
client side.
-jwb
Re: talking about cookies (was: session something...)
On Thu, 11 May 2000, Marc Slemko wrote: In reality, IE's recently publicized hole (which I reported to them, in a slightly modified form, months ago but they didn't see fit to release a patch...) doesn't change much. Hotmail? Yahoo mail? amazon.com? etc. Your cookies for all those sites are vulnerable anyway due to the "cross site scripting" issue. This particular hole in IE doesn't change things too much. Sure, there may be the rare site that isn't vulnerable to cross site scripting. But that is the very rare site, and most sites that think they aren't vulnerable are. Cookies are not secure and will never be secure. I have said it before and will say it again many times before I die. Unfortunately, it isn't as simple as saying "well, don't use cookies". There isn't much in the way of alternatives for a lot of things... Cross-site scripting attacks are hard for most people to wrap their minds around. There are a zillion sites that are vulnerable, mainly because they parrot back to the user whatever they submitted without doing any validation or HTML/URL escaping. Then there are browser bugs that don't treat excaped character properly. Sigh. Mayhaps will we have a cross-site scripting bof at oracon? -jwb
Re: speed up/load balancing of session-based sites
On Tue, 9 May 2000, Gunther Birznieks wrote: As far as I knew Apache::Session has never even had anything to do with cookies. It is a persistent storage mechanism where the session "handle" is a uniquely generated ID. What you are interested in is a Session "manager" which understands how to deal with the workflow around using a persistent storage mechanism. If you want to play with a sample set of modules to do this you may visit http://www.extropia.com/ExtropiaObjects/ The SessionManager code hierarchy provides plug and play cookie, path info, and hidden form variable session managers that wrap around a session hierarchy (of which 90% is wrapped around Apache::Session as the persistent storage mechanism). SessionManager's belong in a different hierarchy than Session because you don't want to couple the storage mechanism to the type of data... eg Someone may want cookies with file based essions, another person might want path info with database sessions, and yet another person might want a cookie based session with database storage. etc... By the by, I have read through and used Gunther's SessionManager code, and I heartily endorse it. It is a useful piece of programming. There is also considerable documentation in book form. Cheers, Jeffrey
Re: speed up/load balancing of session-based sites
I'm more concerned about dealing with large numbers of simultaneous clients (say 20,000 who all hit at 10 AM) and I've run into problems with both dbm and mysql where at a certain point of write activity you basically can't keep up. These problems may be solvable but timings just below the problem threshold don't give you much warning about what is going to happen when your locks begin to overlap. If you are using an RDBMS which has atomic operations, you can turn off locking in Apache::Session with no effect. The current locking scheme in Apache::Session only prevents scrambling the data in non-atomic backing stores like the disk. You can turn locking off by using the NullLocker class. Version 1.5 has an option (called Transaction) which provides transactional read consistency. This is achieved by competely serializing all access. When this option is set, the session object gains an exclusive lock before reading its contents from the backing store, and holds the exclusinve lock until the object is destroyed. On the subject of locking, I think that the daemon locker is going to be the fastest solution for a large-scale operation. Currently, the semaphore locker is the slowest (and also only scales to one machine), and the file locker is only slightly better. -jwb
Re: 100% sessions?
On Tue, 9 May 2000, Tobias Hoellrich wrote: Tom, At 02:02 PM 5/9/00 -0700, Tom Mornini wrote: That is the tricky part. :-) Here's the sneaky way to handle it: Put the Session ID at the beginning of the URI. If a request comes in with a Session ID, then strip it out of $r-urii. If a request comes in without one, redirect them to the same URI with a session ID in place. In our case, this is handled by a trans handler that stores state in $r-pnotes, and a fixup handler that reads $r-pnotes and $r-set_handlers() in the redirect handler into the response phase. The cool thing about this is that relative links need not be rewritten at all, the browser handles it! and what happens when somebody bookmarks a URL with the session-id prepended and comes back a week later with an invalid session-id in the URL? Why is the session ID invalid just because they left for a week? Ask them to authenticate again and take them right back to whatever they were doing. On some sites bookmarking the URL with the session ID embedded is the optimal behavior. -jwb
Re: 100% sessions?
On Tue, 9 May 2000, Tom Mornini wrote: That is the tricky part. :-) Here's the sneaky way to handle it: Put the Session ID at the beginning of the URI. If a request comes in with a Session ID, then strip it out of $r-urii. If a request comes in without one, redirect them to the same URI with a session ID in place. In our case, this is handled by a trans handler that stores state in $r-pnotes, and a fixup handler that reads $r-pnotes and $r-set_handlers() in the redirect handler into the response phase. The cool thing about this is that relative links need not be rewritten at all, the browser handles it! This last part is a great point, and one that people would do well to heed. I hadn't considered the implication that relative URLs would work this way, but they do. I'm excited! I like to use session ids at the beginning of the URL for another reason: the users understand it. For example, if they visit a URL: https://secretstartup.com/home/abcdef0987654321/foo/bar/baz/quux A lot of users are advanced enough to chop off part of the URL to get what they want. With the session ID at the root of the URL, this is easier to do. With this URL, https://secretstartup.com/foo/bar/baz/quux/abcdef0987654321 The users are likely to either not try, or to get it wrong. This works on my site, because the urlspace is completely ficticious. There is no disk path /home/abcdef0987654321, in fact there is no /home, nor even a document root at all. I just threw in the /home to make the URL look a little more friendly. Cheers, Jeffrey
Re: 100% sessions?
On Wed, 10 May 2000, harm wrote: On Tue, May 09, 2000 at 03:36:38PM -0700, Jeffrey W. Baker wrote: The cool thing about this is that relative links need not be rewritten at all, the browser handles it! snip I like to use session ids at the beginning of the URL for another reason: the users understand it. For example, if they visit a URL: https://secretstartup.com/home/abcdef0987654321/foo/bar/baz/quux Ok, that`s convenient, but what if the user follows a link to a different site? Those having access to the logfile of the new site will be able to snoop the sessionid`s if they are fast enough (or have a script monitoring the logfiles) via the referer header. That's a known problem regardless of whether the ID is at the beginning, the end, or in the query string. When linking to non-trusted sites, you must always use an intermediate page to scrub the referer. People leaving my current project appear to have come from /leave. IMHO the browsers should not send Referer when using SSL and jumping from one host to another. -jwb
Re: Running file based sessions via NFS
On Tue, 9 May 2000, John Armstrong wrote: Lots of folks are saying the running File based sessions over NFS is problematic. We are doing it without any noticeable issues so far but I am _very_ curious as to what we need to watch out for. I'd like to meet the evil before I have to do battle with it if you get my drift. If anyone has any insight with some fairly specific examples that would be awesome. We're running our sessions off of a Network Appliance Filer and so far performance is fantastic as is data integrity.. Hahahahaha sigh. Seriously though, you can search this lists' archive for NetApp to get my read on that particular piece of hardware. The bottom line is that it is a very nice machine, but not the flawless miracle that their literature says it is. The problem with NFS is that it takes so long to detect problems. If your platform's NFS timeout is, say, 60 seconds, how many requests are going to stack up while you wait for that timeout to elapse? Once you know there is a problem, does your code deal with it properly? What are you going to do with all those requests that stacked up? How do you tell your application that NFS is available again? We now return you to "All sessions, all the time." -jwb
Re: speed up/load balancing of session-based sites
On Mon, 8 May 2000, Leslie Mikesell wrote: According to Jeffrey W. Baker: I keep meaning to write this up as an Apache:: module, but it's pretty trivial to cons up an application-specific version. The only thing this doesn't provide is a way to deal with large data structures. But generally if the application is big enough to need such data structures you have a real database from which you can reconstruct the data on each request, just store the state information in the cookie. Your post does a significant amount of hand waving regarding people's requirements for their websites. I try to keep an open mind when giving advice and realize that people all have different needs. That's why I prefixed my advice with "On my sites..." Can anyone quantify this a bit? On my sites, I use the session as a general purpose data sink. I find that I can significantly improve user experience by keeping things in the session related to the user-site interaction. These session object contain way more information than could be stuffed into a cookie, even if I assumed that all of my users had cookies turned on. Note also that sending a large cookie can significantly increase the size of the request. That's bad for modem users. Your site may be different. In fact, it had better be! :) Have you timed your session object retrieval and the cleanup code that becomes necessary with server-session data compared to letting the client send back (via cookies or URL) everything you need to reconstruct the necessary state without keeping temporary session variables on the server? There must be some size where the data values are as easy to pass as the session key, and some size where it becomes slower and more cumbersome. Has anyone pinned down the size where a server-side lookup starts to win? I have really extensive benchmarks for every part of Apache::Session. These will be released with version 1.5, which also includes more than fifty new unit tests. Again the performance is very dependent on what you are doing. If everything is on one machine and you are grabbing Storable obejcts from the filesystem, you can retrieve and unStorable the object in time on the order of 100 microseconds (600 MHz Intel/Linux 2.2). If you need to get the object out of a database across the network, network latency will add to that. In larger applications, I would use a private, switch 100 Mb/s ethernet to access the shared backing store, so that latency is not bad. Once again, it depends on your specific needs and implementation. I think storing the state information in a cookie is fine, if you can do it. For me, the state information is larger than what you can shove into a cookie, according to the cookie specification. It simply is not an option for me. I also don't think the cookie storage mechanism is the best thing for the users. If I store the session information on the server side, I can do some pretty tricky stuff. The user could use one computer for a while, go somewhere else, then log in from another computer and I could take him right back to whatever he was doing before. With cookie storage, you can't do that. -jwb
Re: speed up/load balancing of session-based sites
On 7 May 2000, Greg Stark wrote: Further, what are the standard ways to load balance a session-tracking app across multiple servers when the sessions are stored in memory and a given user has to be consistently sent back to the same machine? Can round-robin DNS be counted on to send people back to the same server over the life of a given session? On my sites I use a central database for storing the session objects, and all of the https servers access this central resource. Obviously if it goes down, everything is toast, but the same can be said of the database that stores all of the customer information, etc. I've written some pretty heavy database driven sites that do some pretty complicated things and I've *never* found it really necessary to have a server side session database. In theory you might find it convenient to cache big complex data structures for the session, but in practice most people use it for storing things like usernames and shopping cart contents. My suggestion is to put the state information in the cookie directly. Include a crypto hash (with a secret) to sign the cookie and be done with it. If the information is sensitive then encrypt the whole thing. Then your sessions are completely stateless, they can migrate between mod_perl processes, even across servers. They can even survive server reboots. And They don't require additional infrastructure to store the database of sessions. I keep meaning to write this up as an Apache:: module, but it's pretty trivial to cons up an application-specific version. The only thing this doesn't provide is a way to deal with large data structures. But generally if the application is big enough to need such data structures you have a real database from which you can reconstruct the data on each request, just store the state information in the cookie. Your post does a significant amount of hand waving regarding people's requirements for their websites. I try to keep an open mind when giving advice and realize that people all have different needs. That's why I prefixed my advice with "On my sites..." On my sites, I use the session as a general purpose data sink. I find that I can significantly improve user experience by keeping things in the session related to the user-site interaction. These session object contain way more information than could be stuffed into a cookie, even if I assumed that all of my users had cookies turned on. Note also that sending a large cookie can significantly increase the size of the request. That's bad for modem users. Your site may be different. In fact, it had better be! :) -jwb
Re: Why does $r-print() dereference its arguments?
On Wed, 3 May 2000, Doug MacEachern wrote: On Wed, 3 May 2000, Jeffrey W. Baker wrote: Apache::print() dereferences its arguments. For example, this code: my $foo = "bar"; $r-print(\$foo); prints "bar" instead of the expected SCALAR(0xDEADBEEF). Can anyone explain the purpose of this behavior, or is it a misfeature? In my case, this is not the desired behavior. it only pulls that stunt for strings. assuming you're only printing the reference for debugging purposes, just stringify it first: my $foo = \"bar"; print "$foo"; or, geoff's trick: my $foo = "bar"; print \$foo . ""; do you need to avoid this feature for something other than debugging? Not strictly for debugging, but for introspection. I was toying with a module that pokes around inside the perlguts of a running mod_perl server and makes some nice displays out of them. Nothing for production/money mind you, just amusement. Here is a patch I made against the documentation in Apache.pm. Actually, I had to attach it because it was wrapping. Regards, Jeffrey --- Apache.pm.orig Thu May 4 08:20:59 2000 +++ Apache.pm Thu May 4 08:31:31 2000 @@ -911,7 +911,21 @@ =item $r-print( @list ) This method sends data to the client with C$r-Egtwrite_client, but first -sets a timeout before sending with C$r-Egthard_timeout. +sets a timeout before sending with C$r-Egthard_timeout. This method is +called instead of CORE::print when you use print() in your mod_perl programs. + +This method treats scalar references specially. If an item in @list is a +scalar reference, it will be dereferenced before printing. This is a +performance optimization which prevents unneeded copying of large strings, +and it is subtly different from Perl's standard print() behavior. + +Example: + +$foo = \"bar"; print($foo); + +The result is "bar", not the "SCALAR(0xDEADBEEF)" you might have expected. If +you really want the reference to be printed out, force it into a scalar +context by using print(scalar($foo)). =item $r-send_fd( $filehandle )
Why does $r-print() dereference its arguments?
Apache::print() dereferences its arguments. For example, this code: my $foo = "bar"; $r-print(\$foo); prints "bar" instead of the expected SCALAR(0xDEADBEEF). Can anyone explain the purpose of this behavior, or is it a misfeature? In my case, this is not the desired behavior. -jwb
Re: Why does $r-print() dereference its arguments?
On 3 May 2000, Chip Turner wrote:
"Jeffrey W. Baker" [EMAIL PROTECTED] writes:
Apache::print() dereferences its arguments. For example, this code:
my $foo = "bar";
$r-print(\$foo);
prints "bar" instead of the expected SCALAR(0xDEADBEEF). Can anyone
explain the purpose of this behavior, or is it a misfeature? In my case,
this is not the desired behavior.
If I recall correctly, this is a performance issue. If you have a
large string you want to print, sending a reference will result in
less data copying etc. I don't know how much it pays off, but it is
an intended effect.
You could try something like:
$r-print("@{[\$foo]}");
Or I could just do $r-print(scalar(\$foo));, but that's not my point. My
point is Ewww. I just don't like the overloaded
interface. Does $r-print() take scalars, or references? If it takes
scalars, it shouldn't be dereferencing them. If there is a performance
need for passing references around instead of copying strings, that should
be a different method, perhaps print_ref(). It just seems more clean to
me. Is my mindset too C?
-jwb
