[ANNOUNCE] Apache-AuthenNTLM-2.09
The uploaded file Apache-AuthenNTLM-2.09.tar.gz has entered CPAN as file: $CPAN/authors/id/S/SP/SPEEVES/Apache-AuthenNTLM-2.09.tar.gz size: 96317 bytes md5: 41a1ca630c70730dbcb1601de88fdf16 No action is required on your part Request entered by: SPEEVES (Shannon Eric Peevey) Request entered on: Mon, 07 Feb 2005 12:59:22 GMT Request completed: Mon, 07 Feb 2005 13:00:47 GMT This version of Apache-AuthenNTLM has the following changes: 2.09 07. Feb 2005 - Added notes about KeepAlive Off in httpd.conf file - Added patch from Sergey Svishchev that fixes and issue where each request after the first request on a keep-alive connection used POST data as headers. (Thanks!!) - Added patch that fixed "SMB Server connection not open in state 3" error with Apache2/mp2. (Big thanks to Dr. Russell Mosemann!) take care, -- Shannon Eric Peevey President - EriKin Corporation [EMAIL PROTECTED] (940) 391-6777 http://www.erikin.com
Re: Restricting maximum parallel connections
Pratik wrote: Hi Everyone ! Currently, I am implementing a mechanism to restrict the number of parallel connections to the server from a single client/user. Sounds like you want to disable HTTP Pipelining, am I mistaken? If not, Apache already has a mechanism for this, look in the default httpd.conf firle 1.3x and 2.x for more info. signature.asc Description: OpenPGP digital signature
//scriptname gets script source on https server on Win32
Hello I accidentally entered a wrong URL in my browser and instead of the script output I got the script SOURCE back! The URL is https://my.servername.local//p_reh/myscriptname.pl My mistake was the double / after the server name. Single / works as expected. I can also enter three or more / after the server name and get the script source back. This happens on both my development server and the productive server. May this be a configuration issue? Many thanks for any hints. Josef System configuration: Apache/1.3.27 (Win32) mod_ssl/2.8.14 OpenSSL/0.9.7b mod_perl/1.27_01-dev on NT 4.0 SP6a (development) windows 2000 (productive). DocumentRoot c:/web/ip_virtual/my.servername.local ServerName my.servername.local ErrorLog logs/my.servername.local.ssl.log CustomLog logs/my.servername.local.ssl.access.log combined SSLEngine on SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL SSLCertificateFile "/Apache/conf/ssl.crt/my.servername.local.crt" SSLCertificateKeyFile "/Apache/conf/ssl.key/my.servername.local.key" SSLOptions +StdEnvVars Alias /p_reh/ "c:/web/cgi/p_reh/" SetHandler perl-script PerlHandler Apache::Registry PerlSendHeader On Options +ExecCGI -- Josef Ender, Bitspot AG http://www.bitspot.com
Re: Restricting maximum parallel connections
On Mon, 07 Feb 2005 06:56:44 -0600, Joseph A Nagy Jr <[EMAIL PROTECTED]> wrote: > Sounds like you want to disable HTTP Pipelining, am I mistaken? If not, > Apache already has a mechanism for this, look in the default httpd.conf > firle 1.3x and 2.x for more info. Nop. I am not looking to disable HTTP Pipelining. -Pratik -- http://pratik.syslock.org
[mp1] PERL5LIB handled backwards (mod_perl 1.27+)
The Changes file notes: > PERL5LIB support now properly unshifts paths into @INC rather than push (added in 1.27) While it now does unshift rather than push (so the entries end up at the front of @INC, not the back) it does so backwards! eg: PerlPassEnv PERL5LIB /dir1:/dir2:/dir3 will end up setting @INC to: /dir3 /dir2 /dir1 <[EMAIL PROTECTED]> (you can see this via Apache::Status)
Re: Restricting maximum parallel connections
On Sun, 2005-02-06 at 23:28 -0800, Pratik wrote: > -It does all important operations inside PerlLogHandler. > > -For my requirements - where the request is serving large files for > download - I will need to move those operations in higher level > handlers - Like PerlAccessHandler or PerlInitHandler. I really just intended it as an example of an alternate way to share data without explicit locking. However, I think it's better suited to "X amount within a time window" than to what you're doing, so I'd suggest you stick with Cache::FastMmap. - Perrin
Re: Need help getting DBI to work under mod_perl
So I decided much to my chagrin to reinstall all of my DAMP system. I was able to get apache installed, without being able to start it, as a DSO using the layout=GNU and -enable-shared=max configure options. I probably need to be more selective but, I'll rebuild it once I get it working. The make install on apache_1.3.33 says it's all ok, but when I try and apachectl start it, I get: dyld: /usr/local/sbin/httpd Undefined symbols: _include_module /usr/sbin/apachectl: line 186: 6269 Trace/BPT trap $HTTPD It's the same with compiling mod_perl 1.26. I try to perl MakeFile.PL EVERYTHING=1 DO_HTTP=1 It says ok, but on make I get the following: ld: warning multiple definitions of symbol _regcomp regex/libregex.a(regcomp.o) definition of _regcomp in section (__TEXT,__text) /usr/lib/libdl.dylib(regcomp.So) definition of _regcomp ld: warning multiple definitions of symbol _regexec regex/libregex.a(regexec.o) definition of _regexec in section (__TEXT,__text) /usr/lib/libdl.dylib(regexec.So) definition of _regexec ld: warning multiple definitions of symbol _regfree regex/libregex.a(regfree.o) definition of _regfree in section (__TEXT,__text) /usr/lib/libdl.dylib(regfree.So) definition of _regfree ld: Undefined symbols: _actions_module _include_module _log_config_module make[1]: *** [target_static] Error 1 make: *** [apache_httpd] Error 2 I've tried so many different things and feel like I'm lost in the dark. Anyone know how I can set things strait? On Feb 6, 2005, at 4:16 PM, Boysenberry Payne wrote: I think I figured out what's wrong, but I don't know how to correct it. After reading a web-blog that said to rename any fink created conflicting directories namely /sw/lib/mysql or /sw/lib/perl5 I tried it. Nothing worked afterwords. So, I'm guessing I have conflicting modules being used. Try as I might to reinstall mod_perl I can't get it right. The perl MakeFile.PL asks me to find the apache source directory, which on Mac OS X 10.3 is /usr/include/httpd/ I believe. When I try it the sub directories it looks for the apache handlers are all wrong. I tried ln my /Library/MySQL/lib/mysql/ to the /sw/lib/mysql/ directory to no avail. I needs the following: dyld: /usr/sbin/httpd can't open library: /sw/lib/mysql/libmysqlclient.14.dylib (No such file or directory, errno = 2) [Sun Feb 6 16:08:18 2005] [notice] child pid 779 exit signal Trace/BPT trap (5) Anyone know what my next step is?
Re: [mp1] PERL5LIB handled backwards (mod_perl 1.27+)
[when starting a new thread, please do *not* reply to a previous thread] Gordon Lack wrote: The Changes file notes: PERL5LIB support now properly unshifts paths into @INC rather than push (added in 1.27) While it now does unshift rather than push (so the entries end up at the front of @INC, not the back) it does so backwards! eg: PerlPassEnv PERL5LIB /dir1:/dir2:/dir3 You mean, PerlSetEnv, don't you? PerlPassEnv doesn't accept values. will end up setting @INC to: /dir3 /dir2 /dir1 <[EMAIL PROTECTED]> (you can see this via Apache::Status) Sounds right. Did you forget to attach the patch? :) Though I'm not sure how sensitive that change is. I mean someone who have been relying on the current implementation might get bitten by this change. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [OSCon 2005] rfc Inherited Method Handlers for mod_perl
Nicholas Studt wrote: I'm planning on submitting the following talk proposal for a 45 minute presentation session: Inherited method handlers for mod_perl [...] The only uncertainty I have right now is on on the last section of the talk. I don't know of any project currently using this method, though I have not looked too far. If you know of a project that does use an approach please let me know. The topic is certainly interesting, but I'm confused by the part where you say that you don't know who uses that technique. You mean you came up with that technique/practice w/o using it yourself? -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
[mp2] DESTDIR does not apply to mod_perl.so and includes
${source_dir}/src/modules/perl/Makefile does not reference $(DESTDIR) in
install: rule, so when trying to make mod_perl2 as a relocatable package
mod_perl.so and mod_perl .h files get installed system-wide.
Here's a patch :
--- Makefile.orig2005-02-08 00:43:50.0 +
+++ Makefile2005-02-08 00:32:12.0 +
@@ -101,12 +101,12 @@
install:
# install mod_perl.so
- @$(MKPATH) $(MODPERL_AP_LIBEXECDIR)
+ @$(MKPATH) $(DESTDIR)/$(MODPERL_AP_LIBEXECDIR)
$(MODPERL_TEST_F) $(MODPERL_LIB_DSO) && \
- $(MODPERL_CP) $(MODPERL_LIB_DSO) $(MODPERL_AP_LIBEXECDIR)
+ $(MODPERL_CP) $(MODPERL_LIB_DSO) $(DESTDIR)/$(MODPERL_AP_LIBEXECDIR)
# install mod_perl .h files
- @$(MKPATH) $(MODPERL_AP_INCLUDEDIR)
- $(MODPERL_CP) $(MODPERL_H_FILES) $(MODPERL_AP_INCLUDEDIR)
+ @$(MKPATH) $(DESTDIR)/$(MODPERL_AP_INCLUDEDIR)
+ $(MODPERL_CP) $(MODPERL_H_FILES) $(DESTDIR)/$(MODPERL_AP_INCLUDEDIR)
.SUFFIXES: .xs .c $(MODPERL_OBJ_EXT) .lo .i .s
Re: [OSCon 2005] rfc Inherited Method Handlers for mod_perl
On Mon, 2005-02-07 at 19:50 -0500, Stas Bekman wrote: > Nicholas Studt wrote: > > I'm planning on submitting the following talk proposal for a 45 minute > > presentation session: > > > > Inherited method handlers for mod_perl > [...] > > The only uncertainty I have right now is on on the last section of the > > talk. I don't know of any project currently using this method, though I > > have not looked too far. If you know of a project that does use an > > approach please let me know. > > The topic is certainly interesting, but I'm confused by the part where you > say that you don't know who uses that technique. You mean you came up with > that technique/practice w/o using it yourself? Good point, that is poorly worded. I have been using this method for a couple of years now, but I don't know of any open source projects that are using this method. -- Nicholas Studt <[EMAIL PROTECTED]>
Re: [OSCon 2005] rfc Inherited Method Handlers for mod_perl
Nicholas Studt wrote: On Mon, 2005-02-07 at 19:50 -0500, Stas Bekman wrote: Nicholas Studt wrote: I'm planning on submitting the following talk proposal for a 45 minute presentation session: Inherited method handlers for mod_perl [...] The only uncertainty I have right now is on on the last section of the talk. I don't know of any project currently using this method, though I have not looked too far. If you know of a project that does use an approach please let me know. The topic is certainly interesting, but I'm confused by the part where you say that you don't know who uses that technique. You mean you came up with that technique/practice w/o using it yourself? Good point, that is poorly worded. I have been using this method for a couple of years now, but I don't know of any open source projects that are using this method. So that's your chance to spread the knowledge and then you will see other projects using it. One idea could be to write a tutorial for perl.apache.org, so the technique gets a better visibility. Then you could adopt that text for your presentation. Or vice versa. Whenever I write a tutorial or a presentation I merge that information at perl.apache.org docs and vice versa :) -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2] DESTDIR does not apply to mod_perl.so and includes
Frederic LE GUERN wrote:
${source_dir}/src/modules/perl/Makefile does not reference $(DESTDIR) in
install: rule, so when trying to make mod_perl2 as a relocatable package
mod_perl.so and mod_perl .h files get installed system-wide.
Here's a patch :
--- Makefile.orig2005-02-08 00:43:50.0 +
+++ Makefile2005-02-08 00:32:12.0 +
@@ -101,12 +101,12 @@
install:
# install mod_perl.so
- @$(MKPATH) $(MODPERL_AP_LIBEXECDIR)
+ @$(MKPATH) $(DESTDIR)/$(MODPERL_AP_LIBEXECDIR)
$(MODPERL_TEST_F) $(MODPERL_LIB_DSO) && \
- $(MODPERL_CP) $(MODPERL_LIB_DSO) $(MODPERL_AP_LIBEXECDIR)
+ $(MODPERL_CP) $(MODPERL_LIB_DSO) $(DESTDIR)/$(MODPERL_AP_LIBEXECDIR)
# install mod_perl .h files
- @$(MKPATH) $(MODPERL_AP_INCLUDEDIR)
- $(MODPERL_CP) $(MODPERL_H_FILES) $(MODPERL_AP_INCLUDEDIR)
+ @$(MKPATH) $(DESTDIR)/$(MODPERL_AP_INCLUDEDIR)
+ $(MODPERL_CP) $(MODPERL_H_FILES) $(DESTDIR)/$(MODPERL_AP_INCLUDEDIR)
.SUFFIXES: .xs .c $(MODPERL_OBJ_EXT) .lo .i .s
I understand that you are trying to solve the packager's problem, but I
think this is going to break things for the rest of the world, no?
Also I suppose that your patch just illustrates the issue, since Makefiles
are autogenerated.
--
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2] DESTDIR does not apply to mod_perl.so and includes
> Frederic LE GUERN wrote:
> > ${source_dir}/src/modules/perl/Makefile does not reference $(DESTDIR) in
> > install: rule, so when trying to make mod_perl2 as a relocatable package
> > mod_perl.so and mod_perl .h files get installed system-wide.
> >
> > Here's a patch :
> >
> > --- Makefile.orig2005-02-08 00:43:50.0 +
> > +++ Makefile2005-02-08 00:32:12.0 +
> > @@ -101,12 +101,12 @@
> >
> > install:
> > # install mod_perl.so
> > - @$(MKPATH) $(MODPERL_AP_LIBEXECDIR)
> > + @$(MKPATH) $(DESTDIR)/$(MODPERL_AP_LIBEXECDIR)
> > $(MODPERL_TEST_F) $(MODPERL_LIB_DSO) && \
> > - $(MODPERL_CP) $(MODPERL_LIB_DSO) $(MODPERL_AP_LIBEXECDIR)
> > + $(MODPERL_CP) $(MODPERL_LIB_DSO) $(DESTDIR)/$(MODPERL_AP_LIBEXECDIR)
> > # install mod_perl .h files
> > - @$(MKPATH) $(MODPERL_AP_INCLUDEDIR)
> > - $(MODPERL_CP) $(MODPERL_H_FILES) $(MODPERL_AP_INCLUDEDIR)
> > + @$(MKPATH) $(DESTDIR)/$(MODPERL_AP_INCLUDEDIR)
> > + $(MODPERL_CP) $(MODPERL_H_FILES) $(DESTDIR)/$(MODPERL_AP_INCLUDEDIR)
> >
> > .SUFFIXES: .xs .c $(MODPERL_OBJ_EXT) .lo .i .s
>
> I understand that you are trying to solve the packager's problem, but I
> think this is going to break things for the rest of the world, no?
>
> Also I suppose that your patch just illustrates the issue, since Makefiles
> are autogenerated.
Yes you're right the patch was just intended to make it clear
where the problem was - and also it's here because that's how I solve the
problem temporarily in the package build script, though it's a dirty hack.
Sorry I can't offer a real solution, I'm not a mod_perl developper myself,
I just had to install the package and saw this issue so I thought I'd
mention it.
Regards,
F.
Re: [OSCon 2005] rfc Inherited Method Handlers for mod_perl
On Mon, 2005-02-07 at 21:37 -0500, Stas Bekman wrote: > Nicholas Studt wrote: > > On Mon, 2005-02-07 at 19:50 -0500, Stas Bekman wrote: > > > >>Nicholas Studt wrote: > >> > >>>I'm planning on submitting the following talk proposal for a 45 minute > >>>presentation session: > >>> > >>>Inherited method handlers for mod_perl > >> > >>[...] > >> > >>>The only uncertainty I have right now is on on the last section of the > >>>talk. I don't know of any project currently using this method, though I > >>>have not looked too far. If you know of a project that does use an > >>>approach please let me know. > >> > >>The topic is certainly interesting, but I'm confused by the part where you > >>say that you don't know who uses that technique. You mean you came up with > >>that technique/practice w/o using it yourself? > > > > > > Good point, that is poorly worded. I have been using this method for a > > couple of years now, but I don't know of any open source projects that > > are using this method. > > So that's your chance to spread the knowledge and then you will see other > projects using it. One idea could be to write a tutorial for > perl.apache.org, so the technique gets a better visibility. Then you could > adopt that text for your presentation. Or vice versa. Whenever I write a > tutorial or a presentation I merge that information at perl.apache.org > docs and vice versa :) Hopefully I can start spreading the word at OSCON. I'll submit this proposal tomorrow evening, provided no one has any additional suggestions. -- Nicholas Studt <[EMAIL PROTECTED]>
Re: [mp2] DESTDIR does not apply to mod_perl.so and includes
Frederic LE GUERN wrote:
Frederic LE GUERN wrote:
${source_dir}/src/modules/perl/Makefile does not reference $(DESTDIR) in
install: rule, so when trying to make mod_perl2 as a relocatable package
mod_perl.so and mod_perl .h files get installed system-wide.
Here's a patch :
--- Makefile.orig2005-02-08 00:43:50.0 +
+++ Makefile2005-02-08 00:32:12.0 +
@@ -101,12 +101,12 @@
install:
# install mod_perl.so
- @$(MKPATH) $(MODPERL_AP_LIBEXECDIR)
+ @$(MKPATH) $(DESTDIR)/$(MODPERL_AP_LIBEXECDIR)
$(MODPERL_TEST_F) $(MODPERL_LIB_DSO) && \
- $(MODPERL_CP) $(MODPERL_LIB_DSO) $(MODPERL_AP_LIBEXECDIR)
+ $(MODPERL_CP) $(MODPERL_LIB_DSO) $(DESTDIR)/$(MODPERL_AP_LIBEXECDIR)
# install mod_perl .h files
- @$(MKPATH) $(MODPERL_AP_INCLUDEDIR)
- $(MODPERL_CP) $(MODPERL_H_FILES) $(MODPERL_AP_INCLUDEDIR)
+ @$(MKPATH) $(DESTDIR)/$(MODPERL_AP_INCLUDEDIR)
+ $(MODPERL_CP) $(MODPERL_H_FILES) $(DESTDIR)/$(MODPERL_AP_INCLUDEDIR)
.SUFFIXES: .xs .c $(MODPERL_OBJ_EXT) .lo .i .s
I understand that you are trying to solve the packager's problem, but I
think this is going to break things for the rest of the world, no?
Also I suppose that your patch just illustrates the issue, since Makefiles
are autogenerated.
Yes you're right the patch was just intended to make it clear
where the problem was - and also it's here because that's how I solve the
problem temporarily in the package build script, though it's a dirty hack.
Sorry I can't offer a real solution, I'm not a mod_perl developper myself,
I just had to install the package and saw this issue so I thought I'd
mention it.
sure, but you can help us figure out a solution w/o knowing anything about
mod_perl. The situation of the packagers is unique. One can think of it as
if they are using chroot(1), where their / moves elsewhere. It'd be easy
to make DESTDIR supported, but this is not the right thing. mod_perl has
to be installed where all other Apache modules are. So DESTDIR must not
affect it. Notice that unlike mp1, mp2 does not install mod_perl.so under
the perl tree.
I suppose the simplest solution to this problem is to provide a new
Makefile.PL argument, which will be the same as DESTDIR in the perl world,
but for Apache things. e.g., MP_AP_DESTDIR, so if specified it can be used
exactly as in your patch above. (handling the trailing slash of ofcourse).
In your case MP_AP_DESTDIR will be the same value as DESTDIR.
If you have better ideas please speak up.
--
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
