Re: [OT] New Micro$oft vulnerability?
I was able to change all the PerlSetEnv directives to SetEnv and all seems to be well. There was really no need to set the values so early anyway (since they're only being referenced during content generation). Thanx, Tim. On Fri, Sep 21, 2001 at 02:13:29PM -0600, Nathan Torkington wrote: > > Tim Peoples writes: > > I tried doing the s/OK/DECLINED/ thing and it didn't do the trick. :-( > > > > I forgot to mention that this is in combination with HTML::Mason, > > but I doubt that should have any effect. > > This appears to be a bug in mod_perl, partially (said, I think, Geoff > Young) fixed in the latest version but still not completely > eradicated. I was mistaken with the OK/DECLINED change--that doesn't > make PerlSetEnv work again. > > I don't have a workaround, sorry. I don't know exactly what triggers > the problem (is it PostReadRequestHandler, is it preventing logging, > is it a 408?) It might be that you could use a different phase of the > transaction, and work around it. Sorry I can't be more help. > > Nat -- __ \ \ Timothy E. Peoples \ c o l l e c t i v e Engineering Manager \ \ [EMAIL PROTECTED] Give a man fire and he will be warm for a day, Set a man on fire and he will be warm for the rest of his life.
Re: [OT] New Micro$oft vulnerability?
Hmmm... I tried doing the s/OK/DECLINED/ thing and it didn't do the trick. :-( I forgot to mention that this is in combination with HTML::Mason, but I doubt that should have any effect. Tim. On Tue, Sep 18, 2001 at 03:54:00PM -0600, Nathan Torkington wrote: > > Tim Peoples writes: > > This 'Apache::Vermicide' module, installed as a 'PerlPostReadRequestHandler', > > seems to be preventing any 'PerlSetEnv' directives from being parsed out > > of a '.htaccess' file (or equivalent). IOW, the ENV vars aren't getting > > set properly. > > > > I'm investigating how to remedy this issue. > > Whoops! Returning OK terminates the PostReadRequest phase, > apparently. Changing that to return DECLINED made PerlSetEnv work > again. Sorry, > > Nat -- __ \ \ Timothy E. Peoples \ c o l l e c t i v e Engineering Manager \ \ [EMAIL PROTECTED] What if there were no hypothetical questions?
Re: [OT] New Micro$oft vulnerability?
This 'Apache::Vermicide' module, installed as a 'PerlPostReadRequestHandler', seems to be preventing any 'PerlSetEnv' directives from being parsed out of a '.htaccess' file (or equivalent). IOW, the ENV vars aren't getting set properly. I'm investigating how to remedy this issue. Tim. On Tue, Sep 18, 2001 at 02:01:24PM -0600, Nathan Torkington wrote: > > [Apologies if you get this twice--mailed it first from my oreilly.com > account, which may not be the address subscribed to this list] > > http://www.torkington.com/vermicide.txt has a mod_perl handler to > catch the requests as soon as they arrive, and discard them with a > minimum of work to Apache. If your web server is struggling under the > load, this might help. > > The heuristic it uses for "requests to ignore with prejudice" is the > presence of root.exe, cmd.exe, or default.ida. You might want to > tweak the regexp if those files are part of your web site :-) > > Yes, it's ugly to put the code into your httpd.conf. Consider this a > visual reminder to take it out once the worm scare has passed. > > Nat > -- __ \ \ Timothy E. Peoples \ c o l l e c t i v e Engineering Manager \ \ [EMAIL PROTECTED] AOL -- The longest September on Record
Re: RFD: comp.infosystems.www.modperl
Yet, strangely, *this* thread seems to have threaded nicely (at least
in 'mutt').
Tim.
On Thu, Feb 03, 2000 at 02:54:41PM -0600, Kent Perrier wrote:
>
> "Randal L. Schwartz" wrote:
> >
> > > "John" == John Siracusa <[EMAIL PROTECTED]> writes:
> >
> > John> OTOH, it's a lot easier to track and respond to particular
> > John> issues/problems in a threaded setting like Usenet.
> >
> > Hmm. Get a threaded mailreader. It certainly changed my mail
> > reading. :)
>
> Unfortunately, it appears that many of the MUAs that people use do not
> provide necessary information to properly thread the discussions :(
>
> Kent
>
--
_ _
Timothy E. Peoples |_| C o l l e c t i v e |_|
Senior Consultant |_technologies _|
[EMAIL PROTECTED] [] []
a pencom company
Cupiditas Erodos Probitas
Re: More on web application performance with DBI
On Thu, Oct 14, 1999 at 05:53:15PM -0700, Perrin Harkins wrote:
> On Thu, 14 Oct 1999, Jeffrey Baker wrote:
> > Zero optimization: 41.67 requests/second
> > Stage 1 (persistent connections): 140.17 requests/second
> > Stage 2 (bound parameters): 139.20 requests/second
> > Stage 3 (persistent statement handles): 251.13 requests/second
>
> I know you said you don't like it because it has extra overhead, but would
> you mind trying stage 3 with prepare_cached rather than your custom
> solution with globals? For some applications with lots of SQL statements,
> the prepare_cached appraoch is just much more manageable.
>
> > It is interesting that the Stage 2 optimization didn't gain anything
> > over Stage 1.
>
> I think Oracle 8 is doing some magic by parsing your SQL and matching it
> up to previous statements, whether you use bind variables or not. It may
> matter more on other databases.
>
> - Perrin
You may also find that the use of bind variables become more and more
effecient when used in complex, multi-table joins.
Tim.
--
_ _
Timothy E. Peoples |_| C o l l e c t i v e |_|
Senior Consultant |_technologies _|
[EMAIL PROTECTED] [] []
a pencom company
There is no spoon.
