Rob Nagler wrote:
> Perrin Harkins writes:
> Here's a fun example of a design flaw. It is a performance test sent
> to another list. The author happened to work for one of our
> competitors. :-)
>
>
> That may well be the problem. Building giant strings using .= can be
> incredibly slow
My setup is apache/modperl+Apache::DBI with MySQL driver. On server startup in every
httpd child a few queries that are executed very often are prepared. When the
Apache::Registry scripts run values are bound to the cursors and they are executed.
The server runs ok for 6-10 hours and then I'm
Rob Mueller (fastmail) wrote:
> I recently had a similar problem. A regex that worked fine in sample code
> was a dog in the web-server code. It only happened with really long strings.
> I tracked down the problem to this from the 'perlre' manpage.
>
>WARNING: Once Perl sees that you nee
I recently had a similar problem. A regex that worked fine in sample code
was a dog in the web-server code. It only happened with really long strings.
I tracked down the problem to this from the 'perlre' manpage.
WARNING: Once Perl sees that you need one of "$&", "$`", or "$'"
anywhere in
I know there is some good reference material for mod_perl out there, just
can't remember where. Anybody?
I have two questions...
1. How do I debug the authen/authz phase interactively. I know how
to start my server with -X -D PERLDB and debug the content phase, but
I keep getting 'Subroutine not found' when I try to set break points
on authen/authz methods.
2. I'm trying to use AuthCookieDBI, an
Folks
Unicode refs:
Unicode|HTML|Weaving the Multilingual
Web|http://www.w3.org/Talks/1999/0830-tutorial-unicode-mjd/Overview.html
Unicode|Unicode|http://www-4.ibm.com/software/developer/library/globalsoft.html
Unicode|UTF-8 and Unicode FAQ for
Unix/Linux|http://www.cl.cam.ac.uk/~mgk25/unicode
> When you dig into it, most sites have a lot of data that can be out of sync
> for some period.
Agreed. We run an accounting application which just happens to be
delivered via the web. This definitely colors (distorts?) my view.
> heavy SQL. Some people would say to denormalize the database a
Hi all,
YAJS (Yet Another Job Seeker)?
Laid off from my last company Im looking for a Perl/mod_perl job
preferably in the Bay Area, but may be willing to relocate as well. My
resume can be found at mehryar.com/resume.txt and dont let that little
stint at Microsoft bias ya, I was actually doing mo
> Perrin Harkins writes:
> > To fix this, we moved to not generating anything until it was requested.
We
> > would fetch the data the first time it was asked for, and then cache it
for
> > future requests. (I think this corresponds to your option 2.) Of
course
> > then you have to decide on a ca
> however it comes about is fine, I guess. however, if Apache::Util in 1.3 is left
> un-patched then we're kinda giving a false impression that calling
> Apache::Util::escape_html() is sufficient to thwart CSS attacks when it really only
>keeps
> all but the most clever away.
I guess we shoul
Stas Bekman wrote:
>
> Geoffrey Young wrote:
>
> >>However I'm not sure your patch does the right thing re UTF-8, unless there's
> >>some magic involved that I'm not seeing :-/ I'm no expert on how to deal with
> >>UTF-8 in C (or even in Perl) but it looks like you're only addressing 8bit
> >>en
Geoffrey Young wrote:
>>However I'm not sure your patch does the right thing re UTF-8, unless there's
>>some magic involved that I'm not seeing :-/ I'm no expert on how to deal with
>>UTF-8 in C (or even in Perl) but it looks like you're only addressing 8bit
>>encodings.
>>
>
>
> ok, after some
Perrin Harkins writes:
> To fix this, we moved to not generating anything until it was requested. We
> would fetch the data the first time it was asked for, and then cache it for
> future requests. (I think this corresponds to your option 2.) Of course
> then you have to decide on a cache consi
>
> However I'm not sure your patch does the right thing re UTF-8, unless there's
> some magic involved that I'm not seeing :-/ I'm no expert on how to deal with
> UTF-8 in C (or even in Perl) but it looks like you're only addressing 8bit
> encodings.
ok, after some to and fro with robin over
Robert Landrum wrote:
>
> I just ran this on my system here... It's completely unloaded (load
> average: 0.11, 0.08, 0.02)
>
> Result:
>
> 0 wallclock secs ( 0.06 usr + 0.00 sys = 0.06 CPU) @ 16.67/s (n=1)
>
>
> I ran it on a file that I created with
>
> perl -e "print 'ABCGEFSK' x 25000" > /tmp
Perrin Harkins wrote:
>>Your system has to be swapping horribly. I bet that the ulimit for
>>whoever apache is running as has the memory segment set super low.
>>
apache is running as me on my unloaded desktop (no way this is going to
production until i figure this out). my ulimit -v is unlimi
> I'm interested to know what the opinions are of those on this list with
> regards to caching objects during database write operations. I've
encountered
> different views and I'm not really sure what the best approach is.
I described some of my views on this in the article on the eToys design,
w
> 1) The old cache entry is overwritten with the new.
> 2) The old cache entry is expired, thus forcing a database hit (and
> subsequent cache load) on the next request.
3) Cache only stuff which doesn't expire (except on server restarts).
We don't cache any mutable data, and there are no sessi
On Thu, Jan 24, 2002 at 04:03:30AM -0600, James G Smith wrote:
[snip]
> The most likely suspect that I can think of is the configuration
> being done twice or incompletely the second time, but I don't know
> where else to look.
>
> Anyone have any suggestions? I'll post the code if anyone thinks
On Thursday 24 January 2002 15:34, Geoffrey Young wrote:
> > HTML::Entities correctly turns \x8b into ‹ while Apache::Util leaves
> > it untouched. That character is treated by certain buggy browsers as <
> > and can thus be used to fake tags. Note that just because your browser
> > isn't vulnerab
>
> HTML::Entities correctly turns \x8b into ‹ while Apache::Util leaves it
> untouched. That character is treated by certain buggy browsers as < and can
> thus be used to fake tags. Note that just because your browser isn't
> vulnerable (ie it doesn't buy the fakes h1) doesn't mean that the pro
Andrew Green wrote:
> [My apologies for two copies of my original message turning up. My bad.]
>
> In article <00a901c1a44d$7d087d70$18020c0a@PerriHar>,
>Perrin Harkins <[EMAIL PROTECTED]> wrote:
>
>
>>I would not expect PerlRun to use less memory than Registry.
>>
>
> What I meant was t
I have a module I'm calling ZZZ that provides an Apache conf
directive, ZZZConf, which takes one argument - a file name. This is
then given to an AppConfig object to read in the configuration file.
I am storing this in the $cfg object tied to the section
in which the directive appears.
After
The most common way to abuse is through cookie hijacking,
If an attacker sends an email to a user's webmail account, that
is vulnerable to cross side scripting and the users
opens the message, the attacker would get the user's
session cookies and read the user's email.
There are several attacks
[My apologies for two copies of my original message turning up. My bad.]
In article <00a901c1a44d$7d087d70$18020c0a@PerriHar>,
Perrin Harkins <[EMAIL PROTECTED]> wrote:
> I would not expect PerlRun to use less memory than Registry.
What I meant was that I have about a dozen of these little
Only thing I my self find sofar is that I should be using the
sticky tag under textfield:
textfield(-name=>'fieldsname', -override=>1);
or use force in stead of override..
Ok I did not see that right away but I find the differences in behaviour
quite puzzling.
Arnold van Kampen
On Sat, 1
27 matches
Mail list logo
