Re: use http-equiv to refresh the page
> No, that's "server push" you're thinking of. NPH (non-parsed header) > scripts are CGI scripts that talk directly to the client without the > server parsing headers and adding others (like the one that says it's > Apache). My bad. It was. But I think one needs to use NPH scripts to generate server push documents, IIRC. Which is why I was thinking about it. > Normally, mod_cgi adds the response line and certain other > headers, so it parses your output. This is the same as using mod_perl > with the PerlSendHeader option on. NPH script behave like mod_perl with > PerlSendHeader off. Trust me, you want to leave all the VMS, EBCDIC, and MSIE weirdness related to sending headers in the right order, checking values, including "extras" for broken browsers, and the all-important CRLF-CRLF header separator, et al. to CGI.pm. Mike808/ - http://www.valuenet.net
Re: use http-equiv to refresh the page
On the use of META REFRESH tags, Chris wrote: > It is also the only option for the "pause, then redirect" behavior the > original poster desired that I can think of. I also seem to recall reading in the HTTP spec (and in Lincoln's CGI.pm code) that the use of a Redirect header in response to a POST request was specifically verboten. But, as was noted, everyone does it anyway and it works. Weiqi really needs to look at his apache logs, try running his CGI from the command line to see the exact output the browser sees. Of course, he'll have to manually perform the redirect :=) Use the lwp-request tools (GET and POST) to get live interaction with the webserver in question if running the CGI is not possible. Also, NPH is only implemented in the NS browsers, and was a way for a webserver to send multiple documents "inline" down to a browser, and was an ancient way to write status pages and such that "automagically" refreshed themselves. It was originally used as a primitive way to "animate" images. IE will display these pages as a single never-ending document separated by the headers. If you're running a long-running CGI and need the browser to keep the connection alive, you need to periodically (<2 minutes for IE, but is browser specific) send something to the browser - like a "waiting " page that dribbles out whitespace until the document is ready. There are more complicated ways to do this as well, and that technique is "dated" to modern web users. In any case, I don't think the issue is a mod_perl one, but rather a CGI.pm one. BTW, Weiqi - there is a stlouis.pm perlmongers list. Mike808/ - http://www.valuenet.net
Re: Modperl! Your spam awaits you
On Thursdayen den 1 January 1970 00.59, [EMAIL PROTECTED] wrote: > P.S. This is not spam! Oden Eriksson <[EMAIL PROTECTED]> writes: > He he..., yeah right... > How do one keep this kind of [ed. - expletive] out of here? Michael Poole <[EMAIL PROTECTED]> > I'd like to know, too. On Sunday 04 August 2002 10:04 am, Steven Lembark wrote: > The answer, of course, is Perl. The spamassassin module > to be precise, see <http://www.spamassassin.org> for > details. On Sunday 04 August 2002 10:13 am, Ged Haywood wrote: > No, I think the answer in this case is Ask. From what I can tell, the original had the following header: > X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N So did Ged's last response: > X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N It may have been included when Ged replied, which is how it got attached to his message. Which, in a way allows blocking of spam and spam-related threads, whether it is pro or con the originating message. However, a completely unrelated recent thread had these headers: > Subject: RE: can't fine ModuleConfig.c. > X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N What this tells me is that whatever is performing and inserting the X-Spam-Rating header is worthless to this list for this kind of spam. But, it is always easier to identify ex-post-facto spam than a priori spam. At the very least, the moderators (Ask?) should be able to identify the poster's originating subscribing infromation, unsubscribe them to the list, and/or notify them if it came from a compromised account. And of course, send whatever info we can to the RBL folks (or your favorite public list of spam offenders). Mike808/ -- () Join the ASCII ribbon campaign against HTML email and Microsoft-specific /\ attachments. If I wanted to read HTML, I would have visited your website! Support open standards.
Re: possible buget in CGI.pm
> On Tuesday 23 July 2002 08:27 am, [EMAIL PROTECTED] wrote: > > We do not want CGI.pm to return XHTML ... > > So in Apache::Registry executed scripts we use: > > use CGI qw( -no_xhtml ); > > But on the first invocation it returns normal HTML. On second invocation > > it ignores this directive and returns XHTML. We started a dev server > > with -X to confirm this. It would appear CGI resets its globals > > somewhere. ... > > Some versions: Apache 1.3.26, perl 5.6.1, mod_perl 1.27, CGI 2.81 On Tuesday 23 July 2002 12:47 pm, Lincoln Stein wrote: > I'm aware of the problem, but I haven't been able to track it down. Any > help is welcome. Lincoln, Greg, mod_perl list: The problem appears to be that the -no_xhtml option is only processed in _setup_symbols. This is called only during import() and compile(), and sets $XHTML appropriately. However, $XHTML is reset to 1 in initialize_globals(). _reset_globals() is an alias for this as well. initialize_globals() is called only once in the startup execution (has a comment "Make mod_perl happy") of the module. However, _reset_globals is called during new(), and is registered with mod_perl as a cleanup handler. What this means is that after the first execution, the cleanup handler fires and _reset_globals() is called, which calls initialize_globals(), which then sets the global $XHTML to 1. QED. It looks like -nosticky suffers from the same fate as well, and I would venture to guess that all of the variables reset in initialize_globals() are not being set properly according to the values parsed in _setup_symbols(). e.g. $NPH, $NOSTICKY, $DEBUG, $HEADERS_ONCE, etc. I think the 'undef $NPH' in new() was an attempt to address this for that variable. But it still leaves the rest out in the cold. Because _setup_symbols eats the parameters (the options passed in on the 'use' line), there's no way to call it again later in new() since it ran at compile time. One might "preserve" the options passed in to _setup_symbols() and then have new() call it again with those options to make sure that the new instance retains the options set on the 'use' line. LDS, You might want to separate the option parsing from the autoload magic in _setup_symbols(), and just call the option parsing part with the saved options from the 'use' line in the cleanup handler. Mike808/ -- () Join the ASCII ribbon campaign against HTML email and Microsoft-specific /\ attachments. If I wanted to read HTML, I would have visited your website! Support open standards.
Re: CGI::Carp qw(fatalsToBroswer); question
> Changing a line in CGI::Carp
> < sub ineval { $^S || _longmess() =~ /eval [\{\']/m }
> ---
> > sub ineval { _longmess() =~ /eval [\{\']/m }
> Are there any solutions to this problem that don't involve changing
> CGI::Carp? Perhaps I should just rip the code that I want out of CGI::Carp?
Why not just pull in CGI::Carp and then have some code like:
# Redefine whatever subs we want to directly in the CGI::Carp package
# Just don't expect LDS to support this... :=)
use CGI::Carp;
sub CGI::Carp::ineval { _longmess() =~ /eval [\{\']/m }
I've done the same for many a change to CGI.pm to fix some nits I've run across.
Mike808/
-
http://www.valuenet.net
Re: [OT] Question about Work Wanted ads
> You can not claim donated services as a tax deduction in the US. > (Probably not other places too, I'd guess.) > > The theory is this: you'd have to book both a revenue for the work you > did and a deduction for the donation. These would cancel out. However, this is perfectly legal if you *billed* for your work, were *paid*, and then "voluntarily" cut a check to the charity making an actual cash *donation*. As long as they are bona-fide separate, independent transactions, you can claim the deduction. You can arrange to only "donate" a portion of your time/money this way. Mike808/ - http://www.valuenet.net
Re: CGI::Application
Dodger opined on the : > Grr. Why can't people just write bloody applications with HTML in them > instead of spending so much energy tryuing to find a way to avoid writing > any HTML? Because I don't want to have to go find a!@#$*^$ Perl programmer every time the marketing department or a customer wants their website re-themed. And being a Perl programmer, thank Perl programmers cost more than HTML coders. Because I don't want to have to figure out what *your* code was doing when you wrote it two years ago and are now long, long since gone. *THAT* is why everyone is so interested in Mason, Template, XSLT and all of the other templating technologies. It's a simple business decision. Mike808/ -- () Join the ASCII ribbon campaign against HTML email and Microsoft-specific /\ attachments. If I wanted to read HTML, I would have visited your website! Support open standards.
Re: PDF generation
[EMAIL PROTECTED] wrote: > I also have used html2ps and ps2pdf to make this > transition as well using ImageMagick ( > http://www.imagemagick.org/ ). > > Its a really nice approache since it essentially makes the > sky the limit on your PDF presentation. We did an HR > process for a company once where the users would answer a > bunch of questions and end up with a PDF on their desktop > to print, sign and hand to HR. Ditto. 4 years ago, insurance qualifier for a brokerage firm. The HTML->PDF made a nice "what you see on your screen is what printed at the home office" for the users. And the home office loved not having to decipher mangled handwritten faxes. Another product I've used for (gasp) Java is Root River systems. Very nice report-writer type API with decent page-flow behaviours. Don't know if you can run a JServ+mod_perl or JPerl hybrid, though. Mike808/ -- perl -le "$_='7284254074:0930970:H4012816';tr[0->][ BOPEN!SMUT];print"
Re: performance testing - emulating real world use
> My experience with commercial load-testing apps is that they are > outrageously expensive, a pain to program, don't really scale all that > well, and mostly have to run on Windows with someone sitting at the > mouse. There are some that work better than others, but the free stuff > in this areas is quite good. Ditto. I've found it easier to hack together something with LWP's LWP::UserAgent and Benchmark. Particularly when load-testing an application that required different pre-registered users that had not performed this particular transaction we were load testing. (A survey with random and different questions - depending on the user!). None of the macro-like testing apps could do very much with regard to that kind of interaction and variability in the content generated by the application we were load-testing. But a 30-line Perl script that simply appended the Benchmark results into a tab-delimited file worked great. We found about 30 instances of Perl running the script per WinPC ate the machine. So we only loaded 15 per PC during actual testing and added more distributed nodes to the test. As an aside, the whole thing was an exercise in needing a cup of sugar and asking the local grocery store how much sugar they have on the shelves. i.e. What is the point of measuring beyond the "more than the 1 cup you need"? So we measured (at great expense) and determined that the entire lifetime load (~1yr) expected for all users on their system could be accomplished on the existing sytem during a lunch hour. Mike808/ - http://www.valuenet.net
Re: [OT] email attachments - Win32 email reader to replace OE
Some kind of off-the-cuff reviews from a friend you might find interesting. Note the criterion: <$20 and HTML on/off > I am using Vivian as my main client, but it is lacking in a few "functions" > that need work. It is the ONLY client I have found so far that doesn't > support HTML and it has a really nice "headers view" of the mail on the > server that allows you to choose download, download/delete, delete > before you POP it. It doesn't routinely check your mail for you though. > I "registered" (It's freeware) and sent the guy a few bucks to encourage > his development. > So far, I'm putting my money on POCO as the closest competitor to OE (if > you bar Messenger (I did for HTML reasons)). I have two more to > look at, but so far, nothing promising. I started with two criterion money > (had to be free or less than $20) and be able to turn off HTML/helper > applications (no virus carriers). Mahogany might be promising when the windows > version gets out of beta. So far, this is what I have done : > Outlook Express, Messenger, Pegasus, Iris, PMMail, Mail Warrior, Vivian, > > Hmmm, roll your own with Sylpheed? And what he had to say about The Bat: > Yep, It was very complex. I've heard good and bad talk about it. The HTML > features can't be controlled and the cost made it one of my "no" choices. > I am currently on one of my "finds" and rather liking it. Take a look at > QuickMail Pro. It was written for the MAC, but is rather nice for Doze. > Pricey at $40, but maybe I need to look at some of these... > > (my Doze crashed earlier and I was forced to send before I included all of > the different mail clients I have tried. Quite a few. If I could have > gotten it to work correctly, I'd have stayed with Kaufman Mail Warrior > (my first). I hope that this points those looking in some directions at some of the low-cost alternatives out there. Mike808/ -- perl -le "$_='7284254074:0930970:H4012816';tr[0->][ BOPEN!SMUT];print"
Re: [OT] Re: mod_perl Developer's Cookbook (and Amazon)
> Joe Brenner wrote: > > Spend only $4 more, and you too can show your disgust for > > software patents. Worth every penny. And Barnes and Noble deserves its fair share of disgust for filing counter patent-infringement suits. And since BN now own Fatbrain, so BookPool is my vendor of choice currently for price-conscious book shopping. For niche publishers with small circulation, I try to buy direct from the publisher (e.g. Manning) so that they actually get more of the money I'm spending anyway to keep publishing that kind of work. And AllBookstores.com is now offering it at the same price as Amazon. So now it doesn't cost me anything to show my disgust for software and business model patents. As for the Amazon kickback, well, you have a sucky publisher for not giving you more of your directly generated sales. Mike808/ -- perl -le "$_='7284254074:0930970:H4012816';tr[0->][ BOPEN!SMUT];print"
Re: [OT] pdf creation
Dave Baker wrote: > I ended up using htmldoc (http://www.easysw.com) which does html->pdf in a > breeze (as well as html->ps). So does HTML2PS, which is also GPL'd, and written in 100% Perl. Ghostscript or the Acrobat reader can do the PS2PDF output. See http://www.tdb.uu.se/~jan/html2ps.html Mike808/ -- perl -le "$_='7284254074:0930970:H4012816';tr[0->][ BOPEN!SMUT];print"
Re: Excellent article on Apache/mod_perl at eToys
Nathan Torkington wrote: > I like the idea of P2EE. Yeah. Maybe it will take off better than "Pervlets" did. Mike808/ -- perl -le "$_='7284254074:0930970:H4012816';tr[0->][ BOPEN!SMUT];print"
Re: OT: placeholders and DBI
ryc wrote:
> ... I am having a problem with DBI (or the db) escaping '\n'
> characters so when they are inserted into the database they become '\\n'
> (ie a '\' followed by 'n').
> Does anyone have advice on how this could be done while still using
> placeholders so I dont need to prepare the query more than once?
$sql .= "'\Q$text\E'"
This is also known as the quotemeta function.
You might want to investigate the use of the statement handle method "quote".
quote
$sql = $dbh->quote($value);
$sql = $dbh->quote($value, $data_type);
Quote a string literal for use as a literal value in an SQL statement, by
escaping
any special characters (such as quotation marks) contained within the string
and
adding the required type of outer quotation marks.
$sql = sprintf "SELECT foo FROM bar WHERE baz = %s", $dbh->quote("Don't");
Taken straight from the perldocs for "DBI".
mike808/
--
perl -le "$_='7284254074:0930970:H4012816';tr[0->][ BOPEN!SMUT];print"
Re: URI::URL - problem in LWP 5.53_95 with mod_perl
___cliff rayman___ wrote: > i did not use CPAN.pm to install software on this particular > machine. my mod_perl builds are always by hand. > > i did understand exactly why this happened. i should have made > that more clear in my first e-mail. i made the patch that i did, so > i would not have the same problem with any other software. You are correct. I interviewed the sysadmin that called me for help with this building mod_perl, and he fessed up to FTP'ing into CPAN and just grabbing the "latest version" - i.e. the 5.53_95 tarball. He didn't use CPAN.pm after all. I couldn't get CPAN.pm to fetch the dev tarball either. I just figured he was too new to Perl and Solaris (a former MCSE) to grab a tarball and install. Turns out, he was too new. He just didn't know about CPAN.pm! Anyway, I missed your (Cliff's) one-line patch to LWP::UserAgent.pm and thought it was the more extensive earlier patch. My vote is for Cliff's patch to just 'use URI::URL;' in LWP::UserAgent.pm. If you don't feel like patching, remember to export PERL_HTTP_URI_CLASS=URI::URL instead. Mike808/ > Stas Bekman wrote: > > What version of CPAN.pm are you using? CPAN.pm never picks distros with > > '_' in the version part. I've just performed checking I've got > > 5.53.tar.gz. Then you shouldn't be having the missing URI::URL problem in mod_perl. Or has the "real" 5.53 been fubar'd since April or so, and nobody noticed until now? Mike808/ -- perl -le "$_='7284254074:0930970:H4012816';tr[0->][ BOPEN!SMUT];print"
Re: URI::URL - problem in LWP 5.53_95 with mod_perl
I ran into the same problem. Found a simpler, cleaner solution.
Just perform a
export PERL_HTTP_URI_CLASS=URI::URL
before building mod_perl, and you're home free.
Long term, all mod_perl testing modules that "assume" URI::URL
is loaded by LWP will now need to explicitly load URI::URL if they use it.
I suggest doing so following the loading of LWP.
Here's why it happened:
Cliff noted:
>I noticed everywhere that URI::URL was being used in mod_perl and embperl,
>LWP::UserAgent was being used.
>
>also, i found this is the LWP (libwww-perl-5.5395) release notes:
>
> HTTP::Request, HTTP::Response will by default now use "URI" class,
> instead of "URI::URL", when constructing its URI objects. This
> has a potential for breaking existing code as URI::URL objects had
> some extra methods that external code might depend upon.
He's right, and this is exactly what's happened in mod_perl.
It's a bug *caused* by recent changes in LWP, and not a bug in LWP, per se.
>From Gisle Aas' directory in CPAN, you can see:
04/10/01 06:15PM157,267 libwww-perl-5.53.tar.gz
05/05/01 08:57AM172,925 libwww-perl-5.53_94.tar.gz
08/06/01 07:46PM174,613 libwww-perl-5.53_95.tar.gz
>From the "official" website, http://www.linpro.no/lwp, he says the
lastest version is 5.53 from 4/10/01. However, if you use the CPAN module,
you will pickup the 5.53_95 version instead. This is the version (and
maybe 5.53_94 as well, but I haven't checked) that makes mod_perl break.
Or maybe some interim versions of the CPAN module are downloading
this development version of the module, I'm not sure.
I'm willing to bet that both of you have the later 5.53_95 rev and not
the 5.53 version.
Here's the cause of the problem. Gisle has always used URI::URL for
representing his URLs within LWP. These latest revs changed that.
He now uses a base URI class. The effect of this is that LWP no longer
uses URI::URL. Meaning URI::URL is no longer 'use'd by LWP, and so
LWP will no longer automatically 'use' URI::URL and pull it in too.
This is what's making mod_perl (and any other modules that do this) break.
Using LWP *does not* load URI::URL. mod_perl's tests *assume* that just
because LWP was loaded, that URI::URL was too. And that's the hidden
dependency that's being violated here.
So, where's the root of the cause of the code breakage in LWP, you ask?
Way down in HTTP::Message (which is inherited by HTTP::Request and
HTTP::Response), Gisle has changed it to use the bare URI class and not
the older URI::URL class.
Here's the line of code that does the damage (Line 37 in HTTP::Message.pm):
$HTTP::URI_CLASS ||= $ENV{PERL_HTTP_URI_CLASS} || "URI";
As should be obvious now, my simple solution is to perform a
export PERL_HTTP_URI_CLASS=URI::URL
before building mod_perl, and you're home free.
Michael King
[EMAIL PROTECTED]
-
Valuenet Web Mail.
http://www.valuenet.net/
