Has anyone been able to use Apache::AuthenSmb on Windows? I'm trying to
setup our UNIX Apache environment on a Windows box, but I'm having
trouble compiling Authen::Smb. Actually, a better question might be,
does anyone have any ideas on the best approach of implementing web
authentication a
Eric Sammer wrote:
answering just the first part of the question:
If I recall, Apache->request() was being deprecated (or at least frowned
upon)... Is this true?
It's deprecated in mod_perl 2.0, not in mod_perl 1.0. Apache->request() has
very little to do with Apache::Request.
___
Awhile back, I encountered this same problem and found a solution from
Matt Arnold's mod_perl post, which I cannot locate at the time. Anyhow,
here's the fix that I've been using in our production environment.
1. Update Authen::Smb like so:
use Fcntl qw(:flock);
...
open S, "> /full/path/to/A
Sorry if this is OT.
If I recall, Apache->request() was being deprecated (or at least frowned
upon)... Is this true? Also, (and I know it's a separate package, but)
does anyone know if the same is true for Apache::Request->instance()?
With regard to A::R->instance(), I ask because I was running
Lincoln Stein wrote:
$q = CGI->new(\*FH);
I've read the source code of init() and it seems that if you pass the
filehandle in this way, it never reaches read_from_client as you use this fh
to populate $query_string right there in init().
The only place it's used is in:
$fh = to_fileha
Matthew Darwin wrote:
Stas Bekman wrote:
I'd suggest to take whatever data you s/// and try it outside mod_perl
first. May be your filter or some previous filter has truncated the
UTF-8 char in the middle? You should be aware that other filters are
not aware of the encoding, and they just giv
Stas Bekman wrote:
I'd suggest to take whatever data you s/// and try it outside mod_perl
first. May be your filter or some previous filter has truncated the
UTF-8 char in the middle? You should be aware that other filters are not
aware of the encoding, and they just give you the amount of dat
Matthew Darwin wrote:
I'm just wondering if anyone has any input on this issue. I'm
implementing an output filter, like so:
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
PerlOutputFilterHandler Apache::Kinnetics::Output
and I get the following error on some web pages that have U
Lincoln Stein wrote:
What it does now (in the version I sent out this AM) is to check whether the
filehandle is STDIN. If not, it reverts to the old code. Otherwise it uses
yours. Sound OK to you?
No, this doesn't work:
$fh eq \*STDIN
because it can be:
GLOB(0x86af9d8)
main::STDIN
STDIN
th
I'm just wondering if anyone has any input on this issue. I'm
implementing an output filter, like so:
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
PerlOutputFilterHandler Apache::Kinnetics::Output
and I get the following error on some web pages that have UTF-8 data:
[Wed Nov 0
$q = CGI->new(\*FH);
Lincoln
On Wednesday 05 November 2003 02:50 pm, Stas Bekman wrote:
> Lincoln Stein wrote:
> > No, it made sense for the fastCGI and original Apache::Request modules.
> > The CGI state data potentially comes from many sources: sometimes from
> > stdin and sometimes from mod_p
OK, I've traced through stuff. The current proposed fix will break the
ability to read and write CGI state to temporary files, database handles, etc
when operating under mod_perl. Possibly some of the persistent state engines
use this, but I think I'll leave it as a known bug.
Lincoln
On Mon
Hi Stas,
Actually the read_from_client method() is supposed to be overridden in
subclasses so that it can read directly from mod_perl, fastCGI, etc. The
thing's a mess at this point, and so I'm going to close my eyes, fold in
Scott's changes, release it to the world, and hope nothing breaks.
What it does now (in the version I sent out this AM) is to check whether the
filehandle is STDIN. If not, it reverts to the old code. Otherwise it uses
yours. Sound OK to you?
Lincoln
On Wednesday 05 November 2003 03:05 pm, Stas Bekman wrote:
> Lincoln Stein wrote:
> >>Lincoln Stein wrote:
Leo Lapworth wrote:
Hi All,
The first version is available at:
http://leo.cuckoo.org/projects/AuthCookieNTLM/
I'll tidy up the docs and add a bit more functionality tomorrow,
debugging for example! - before uploading to CPAN.
We decided against using Apache::AuthCookie in the end,
it just seeme
On Wed, 2003-11-05 at 16:39, Frantzcy Paisible wrote:
> The Slow part of my application is on HUGE function that overuses XML::Twig.
You should look at that section to see if you can either cache part of
it or change your approach.
> That and a do 'config.lib'.. that I cannot easely get rid of.
Well, for startup and db connecting... it has done it's job.
The Slow part of my application is on HUGE function that overuses XML::Twig.
That and a do 'config.lib'.. that I cannot easely get rid of.
I'm wondering if there are knowned issues with mod_perl <-> XML::Twig.
Frantzcy
On 05 Nov
Christian Wetzig wrote:
Stas Bekman wrote:
[...]
It's a known problem. I'll commit a fix soonish (I need to do some
extra testing and rewrites). Meanwhile please replace
- read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
+ $r->read($buffer, $ENV{'CONTENT_LENGTH'});
That should do the trick.
thank
Stas Bekman wrote:
[...]
It's a known problem. I'll commit a fix soonish (I need to do some extra
testing and rewrites). Meanwhile please replace
- read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
+ $r->read($buffer, $ENV{'CONTENT_LENGTH'});
That should do the trick.
thanks a lot, works fine. is th
Lincoln Stein wrote:
Lincoln Stein wrote:
No, it made sense for the fastCGI and original Apache::Request modules.
The CGI state data potentially comes from many sources: sometimes from
stdin and sometimes from mod_perl.
That part is clear, and we are good here. But you said something different.
Lincoln Stein wrote:
Hi Folks,
Please test out the following alpha release of CGI.pm 3.01. Things that need
to be examined:
- regularly POST
- multipart POST
- file upload
These were tested with only with mod_perl 2 with our own tests.
- saving state to files/pipes and
Lincoln Stein wrote:
No, it made sense for the fastCGI and original Apache::Request modules. The
CGI state data potentially comes from many sources: sometimes from stdin and
sometimes from mod_perl.
That part is clear, and we are good here. But you said something different.
You said that read_f
Hi All,
The first version is available at:
http://leo.cuckoo.org/projects/AuthCookieNTLM/
I'll tidy up the docs and add a bit more functionality tomorrow,
debugging for example! - before uploading to CPAN.
We decided against using Apache::AuthCookie in the end,
it just seemed over kill.
By de
Christian Wetzig wrote:
Hi,
the following worked fine under 1.99_09 in a perl module called from a
simple mod_perl script (SetHandler perl-script, PerlHandler
ModPerl::Registry):
> read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
But after upgrading to 1.99_10, the content of $buffer stops after
Wilt, Paul wrote:
Stas:
Actually there is continued overhead due to the fact that different
instructions (that require a larger number of cycles to decode / dispatch)
are used when calling subroutines and / or accessing memory in a shared
environment.
That would be a very badly designed shared lib
Lincoln Stein wrote:
OK, I've traced through stuff. The current proposed fix will break the
ability to read and write CGI state to temporary files, database handles, etc
when operating under mod_perl. Possibly some of the persistent state engines
use this, but I think I'll leave it as a known
Tested and working on my mod_perl 2 with ModPerl::Registry setup.
Your scripts from /examples below work, and my problems from earlier
on are not seen.
Thanks,
Scott Beuker
> -Original Message-
> From: Lincoln Stein [mailto:[EMAIL PROTECTED]
> Sent: November 5, 2003 7:11 AM
> To: Stas Bek
On Wed, 2003-11-05 at 10:13, Frantzcy Paisible wrote:
> From the examples, small ones, the performance gains are like 200 to one and more.
> But on real applications, like on bigger, more complicated scripts, what is to be
> expected ?
mod_perl helps with startup costs and connections to the dat
Yes, thank you, But I went through that one already...
Maybe I shouw change my question to
Anyone having issued with XML::Twig performance on top of mod_perl ?
Frantzcy
On Wed, 5 Nov 2003 15:08:20 +0100,Thomas Klausner <[EMAIL PROTECTED]> wrote:
> Hi!
>
> On Wed, Nov 05, 2003 at 10:13:38
Hi,
the following worked fine under 1.99_09 in a perl module called from a
simple mod_perl script (SetHandler perl-script, PerlHandler
ModPerl::Registry):
> read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
But after upgrading to 1.99_10, the content of $buffer stops after the
header of the first
Hi!
On Wed, Nov 05, 2003 at 10:13:38AM -0500, Frantzcy Paisible wrote:
> Does anyone have a list of tips and/or tricks that could help improuve
> performance ?
http://perl.apache.org/docs/1.0/guide/performance.html
--
#!/usr/bin/perl http://domm.zsi.at
for(ref bl
Hello everyone,
I have some questions about performance of mod_perl.
>From the examples, small ones, the performance gains are like 200 to one and more.
But on real applications, like on bigger, more complicated scripts, what is to be
expected ?
I've converted a perl application last month.
Stas:
Actually there is continued overhead due to the fact that different
instructions (that require a larger number of cycles to decode / dispatch)
are used when calling subroutines and / or accessing memory in a shared
environment.
Paul E Wilt
Senior Principal Software Engineer
ProQuest Inform
Hello Stas,
Wednesday, November 05, 2003, 3:11:21 PM, you wrote:
SB> Is it possible that you import functions with the same name from different
SB> modules into the same script? If not, you really need to show us some *very*
SB> short examples of your code so we can get the idea what your proble
Gisle Aas wrote:
Stas Bekman <[EMAIL PROTECTED]> writes:
Hmm, I wonder about this para from that file:
---
In terms of performance, on my test system (Solaris 2.5_x86) the perl
test suite took roughly 15% longer to run with the shared libperl.so.
Your system and typical applications may well giv
Andrey A. Kudrin wrote:
Hello Stas,
Wednesday, November 05, 2003, 4:54:01 AM, you wrote:
I have a mod_perl driven website and CMS for this site running under
PerlRun. Site and CMS located in different direcories and use
different modules, but have subroutines that have the same names.
From some
Hello Stas,
Wednesday, November 05, 2003, 4:54:01 AM, you wrote:
>> I have a mod_perl driven website and CMS for this site running under
>> PerlRun. Site and CMS located in different direcories and use
>> different modules, but have subroutines that have the same names.
>>>From some moment site b
Stas Bekman <[EMAIL PROTECTED]> writes:
> Hmm, I wonder about this para from that file:
>
> ---
> In terms of performance, on my test system (Solaris 2.5_x86) the perl
> test suite took roughly 15% longer to run with the shared libperl.so.
> Your system and typical applications may well give quit
On Mon, 3 Nov 2003, Joe Schaefer wrote:
> The first developer release of libapreq2 is underway. This
> package provides the Perl modules Apache::Request and
> Apache::Cookie for modperl-2, and requires the following:
>
> apache2 w/ mod_so: 2.0.46
>libapr: 0.9.4
>
--- Stas Bekman <[EMAIL PROTECTED]> wrote: > Sreeji K
Das wrote:
> mod_perl build currently requires that
> makepl_args.mod_perl is present in one of
> > current, '..' or $ENV{HOME}.
> ...
> Why not do the simple:
>
> perl Makefile.PL `cat
> /whereever/your/file/is/makepl_args.mod_perl`
Then
40 matches
Mail list logo
