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, 12
[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
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
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 Location section
in which the directive appears.
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 that I have
HTML::Entities correctly turns \x8b into #139; 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
On Thursday 24 January 2002 15:34, Geoffrey Young wrote:
HTML::Entities correctly turns \x8b into #139; 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
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
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
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,
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 unlimited.
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/seqdata
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 on
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
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
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 to and fro
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
encodings.
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 should
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
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 at
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
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,
I know there is some good reference material for mod_perl out there, just
can't remember where. Anybody?
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 the
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 need
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; Perl
stas02/01/24 06:53:35
Modified:Apache Apache.pm
Log:
- escape chars
Revision ChangesPath
1.70 +5 -5 modperl/Apache/Apache.pm
Index: Apache.pm
===
RCS file:
dougm 02/01/24 20:04:12
Modified:xs/tables/current/Apache FunctionTable.pm
xs/tables/current/ModPerl FunctionTable.pm
Log:
sync
Revision ChangesPath
1.31 +72 -6 modperl-2.0/xs/tables/current/Apache/FunctionTable.pm
Index: FunctionTable.pm
dougm 02/01/24 20:04:22
Modified:src/modules/perl modperl_filter.c modperl_filter.h
xs/Apache/Filter Apache__Filter.h
xs/maps apache_functions.map
Log:
adjust to ap_get_brigade() API change
Revision ChangesPath
1.31 +3 -3
29 matches
Mail list logo
