Geoffrey Young wrote:
the Apache-Test/ subdirectory of the perl-framework has migrated to a new
location:
https://svn.apache.org/repos/asf/perl/Apache-Test
what this means for you is that you need to manually adjust your checkout
$ rm -rf Apache-Test/
$ svn update
ugh, rm is not a good idea
Stas Bekman wrote:
Geoffrey Young wrote:
the Apache-Test/ subdirectory of the perl-framework has migrated to a new
location:
https://svn.apache.org/repos/asf/perl/Apache-Test
what this means for you is that you need to manually adjust your checkout
$ rm -rf Apache-Test/
$ svn
Hi,
in TestConfigPerl we have this logic and comment
# modules like Embperl.so need mod_perl.so to be loaded first,
# so make sure that it's loaded before files inherited from the
# global httpd.conf
$self-preamble_first(IfModule = '!mod_perl.c', $cfg);
what this does
Also Geoff please don't forget to update the documentation. Both inside
the module and at perl.apache.org docs. Thanks.
I couldn't find any mentions of the location of the repository outside of
README-SVN. do you know of others?
additionally, we should probably update httpd.apache.org/test
Hi,
I'm looking for some suggestions for a library problem with Apache::Test,
which I'm using to develop a web application.
Hope this is the place to ask.
Using Apache 1 and Mod perl 1, how can I preload perl modules at server
startup?
My extra.conf.in contains something like this:
PerlModule
Jim Martinez wrote:
Hi,
I'm looking for some suggestions for a library problem with Apache::Test,
which I'm using to develop a web application.
Hope this is the place to ask.
better [EMAIL PROTECTED] now, but that list was just created yesterday :)
Using Apache 1 and Mod perl 1, how
may be we should be more flexible right away and use the same approach
Apache uses, i.e. have each custom module a say for its insertion
priority. So we could add mod_perl as middle module and give other
modules an opportunity to load themselves before (first/very_first or
after
Geoffrey Young wrote:
in general, I think it is atypical that one apache module depends on another
module being loaded before it itself can load. that is, in a LoadModule
sense - sure, lots of things depend on mod_perl, but they use PerlModule not
LoadModule. embperl seems to be the exception to
Christopher H. Laco wrote:
Geoffrey Young wrote:
in general, I think it is atypical that one apache module depends on
another
module being loaded before it itself can load. that is, in a LoadModule
sense - sure, lots of things depend on mod_perl, but they use
PerlModule not
LoadModule.
Geoffrey Young wrote:
Also Geoff please don't forget to update the documentation. Both inside
the module and at perl.apache.org docs. Thanks.
I couldn't find any mentions of the location of the repository outside of
README-SVN. do you know of others?
if you don't find any with grep, then there
Geoffrey Young wrote:
+1
Index: TestRunPerl.pm
===
--- TestRunPerl.pm (revision 153110)
+++ TestRunPerl.pm (working copy)
@@ -35,6 +35,9 @@
# Apache::TestConfigPerl already configures mod_perl.so
Stas Bekman wrote:
Geoffrey Young wrote:
Also Geoff please don't forget to update the documentation. Both inside
the module and at perl.apache.org docs. Thanks.
I couldn't find any mentions of the location of the repository outside of
README-SVN. do you know of others?
if you don't find any
if you don't find any with grep, then there are none. So we should add
one then :)
:)
yes, now that it's officially ours we should do more to publicise it.
additionally, we should probably update httpd.apache.org/test and
create a
home for Apache-Test under perl.apache.org.
I see
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 09, 2005 2:39 AM
New Revision: 152973
[...]
+/* RFC 2616 10.3.5 states that entity headers are not supposed
+ * to be in the 304 response. Therefore, we need to load in the
+ * cached headers
Hi,
I'm new to apache.
I've built httpd-2.1 out of the latest cvs. I got the following
warning
messages during installation:
Installing build system files
libtool: install: warning:
`/usr/local/src/apache/httpd-2.1/srclib/aprutil/libaprutil-1.la' has not
been
Hi,
Justin Erenkrantz [EMAIL PROTECTED] writes:
Okay, please try again. =) I've committed fixes in r152973: these
should go some way to addressing these problems.
works fine now!
Thank you,
David
ap_log_error escapes escape sequences such as newline and tab so that
they appear as the two-character strings \t or \n in error_log
(unless httpd was
built with -DAP_UNSAFE_ERROR_LOG_UNESCAPED) as fallout from CAN-2003-0020
Some callers throughout the code still send '\n' within the string
On Wed, 9 Feb 2005 09:36:09 -0500, Eric Covener [EMAIL PROTECTED] wrote:
ap_log_error escapes escape sequences such as newline and tab so that
they appear as the two-character strings \t or \n in error_log
(unless httpd was
built with -DAP_UNSAFE_ERROR_LOG_UNESCAPED) as fallout from
--On Wednesday, February 9, 2005 10:47 AM +0100 Sander Striker
[EMAIL PROTECTED] wrote:
[...]
+/* RFC 2616 10.3.5 states that entity headers are not supposed
+ * to be in the 304 response. Therefore, we need to load in the
+ * cached headers before we update the cached
From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 09, 2005 6:20 PM
[...]
Hence, the response headers from the origin server on a 304 response aren't
guaranteed to be complete. So, what this commit does now is load in the
stored cached response headers and
I'd like to see what we can do to minimize our need to always recompile
buildmark.c. Ideally, it should only need to be recompiled if httpd is
being relinked for some other reason - not every single time make is run.
One possibility might be to do something via the $(PROGRAM_NAME) target in
Forgive me if this has already been mentioned, but I can't find anything
in the archives. Is anybody planning on packaging a Windows version of
the source files?
Thanks,
Alex.
I did exactly that for win32.
The old win32 build system recompiled buildmark.c as a build
step (bleh.) The new win32 build system has the compilation
of buildmark.c as a prelink step - if we aren't linking libhttpd,
we don't recompile buildmark.
Seemed to be a trivial solution, and avoided
Yes to both (source files, and binaries).
Forgive, it's been a busy week and as .53 isn't a security
release, this hasn't been at the top of my agenda :)
Promise, the next security release, binaries + source .zip
balls will be in-sync with the announce.
Bill
At 02:55 PM 2/9/2005, Alex Varju
Quoting Bojan Smojver [EMAIL PROTECTED]:
I'm trying to rely on functions that help in creating sub-requests,
Actually, that would be requests as well, not just sub-requests.
--
Bojan
25 matches
Mail list logo
