On Mon, Jul 12, 2004 at 05:03:50PM -, [EMAIL PROTECTED] wrote:
--- errordoc.t 12 Jul 2004 16:44:47 - 1.2
+++ errordoc.t 12 Jul 2004 17:03:49 - 1.3
@@ -59,8 +59,7 @@
'/redefine/notfound.html code');
# 1.3 requires quotes for
This makes the test fail against 2.0.50, but it's just a lack-of-feature
right, so OK if I half-revert this?
the last time I asked about this, the consensus was that the perl-framework
is expected to be for developer use only, expected to run (and in some cases
compile) successfully only on
On Fri, Jul 16, 2004 at 09:08:42AM -0400, Geoffrey Young wrote:
This makes the test fail against 2.0.50, but it's just a lack-of-feature
right, so OK if I half-revert this?
the last time I asked about this, the consensus was that the perl-framework
is expected to be for developer use
Why not use L for links in the docs?
--- src/docs/general/testing/testing.pod.~1.33.~ Sat May 1 16:53:19
2004
+++ src/docs/general/testing/testing.pod Fri Jul 16 10:36:15 2004
@@ -3167,7 +3167,7 @@
to test any web application from end to end based application as if it
were a black box
Hi All,
Still looking at the testing.pod, I see list items like this:
=over
=item * -order=rotate
rotate the tests: a, b, c, a, b, c
=item * -order=repeat
repeat the tests: a, a, b, b, c, c
=item * -order=random
run in the random order, e.g.: a, c, c, b, a, b
=back
I think that's generally
On Jul 16, 2004, at 10:46 AM, David Wheeler wrote:
Hi All,
Still looking at the testing.pod, I see list items like this:
Oops, wrong list for these questions. Apologies. Moving over to
docs-dev...
Regards,
David
David Wheeler wrote:
Why not use L for links in the docs?
Because it's not supported by Pod::POM and wasn't part of the
perlpodspec until recently. Pod::POM detects and auto-links http:// refs
on its own, without needing L.
--- src/docs/general/testing/testing.pod.~1.33.~Sat May 1 16:53:19
David Wheeler wrote:
Hi All,
I expect that there was a reason that these links were created as they
were?
% podchecker -nowarnings src/docs/general/testing/testing.pod
*** ERROR: unresolved internal link 'Writing_Tests' at line 89 in file
src/docs/general/testing/testing.pod
*** ERROR:
David Wheeler wrote:
% cvs ci -m 'Remove empty list item.' src/docs/general/testing/testing.pod
cvs.apache.org: Connection refused
cvs [commit aborted]: end of file from server (consult above messages if
any)
works fine for me
--
__
David Wheeler wrote:
Hi All,
Still looking at the testing.pod, I see list items like this:
=over
=item * -order=rotate
rotate the tests: a, b, c, a, b, c
=item * -order=repeat
repeat the tests: a, a, b, b, c, c
=item * -order=random
run in the random order, e.g.: a, c, c, b, a, b
=back
I think
On Jul 16, 2004, at 12:40 PM, Stas Bekman wrote:
Because it's not supported by Pod::POM and wasn't part of the
perlpodspec until recently. Pod::POM detects and auto-links http://
refs on its own, without needing L.
Okay.
David
smime.p7s
Description: S/MIME cryptographic signature
On Jul 16, 2004, at 12:48 PM, Stas Bekman wrote:
Without * it won't generate the bullets. I wanted the bullets so * is
there.
Okay.
David
smime.p7s
Description: S/MIME cryptographic signature
I don't understand why mod_cache forcedly avoids caching URLs ending
with the / (slash) character.
Apparently EGP (who's he?) agrees.
Anyhow, it's several months that we're running with this patch in
production, and nothing bad seems to be happening.
Pier
diff -U3 -wr
Pier Fumagalli wrote:
I don't understand why mod_cache forcedly avoids caching URLs ending
with the / (slash) character.
Apparently EGP (who's he?) agrees.
Anyhow, it's several months that we're running with this patch in
production, and nothing bad seems to be happening.
If it works, I say
On Fri, 16 Jul 2004, Graham Leggett wrote:
Pier Fumagalli wrote:
I don't understand why mod_cache forcedly avoids caching URLs ending with
the / (slash) character.
Apparently EGP (who's he?) agrees.
Anyhow, it's several months that we're running with this patch in
production, and nothing bad
Graham Leggett wrote:
If it works, I say commit the patch. Can think of no reason why we
should not cache an URL ending is /.
Because the cache_in filter gets added in the quick_handler. The
fast_internal_redirect in mod_dir which translates / to /index.html (or
whatever) seems to lose this
Brian Akins wrote:
If it works, I say commit the patch. Can think of no reason why we
should not cache an URL ending is /.
Because the cache_in filter gets added in the quick_handler. The
fast_internal_redirect in mod_dir which translates / to /index.html (or
whatever) seems to lose this
Er. Hi.
These remarks are in reference to source code published at
http://httpd.apache.org/docs-2.0/developer/request.html.
switch (ap_satisfies(r)) {
case SATISFY_ALL:
case SATISFY_NOSPEC:
...
Seems to me the case for SATISFY_ALL does nothing useful. Is there a
missing break statement? If
* Craig Woodford [EMAIL PROTECTED] wrote:
These remarks are in reference to source code published at
http://httpd.apache.org/docs-2.0/developer/request.html.
switch (ap_satisfies(r)) {
case SATISFY_ALL:
case SATISFY_NOSPEC:
...
Seems to me the case for SATISFY_ALL does nothing useful.
On 16 Jul 2004, at 15:13, Graham Leggett wrote:
Brian Akins wrote:
If it works, I say commit the patch. Can think of no reason why we
should not cache an URL ending is /.
Because the cache_in filter gets added in the quick_handler. The
fast_internal_redirect in mod_dir which translates / to
Pier Fumagalli wrote:
On 16 Jul 2004, at 15:13, Graham Leggett wrote:
Brian Akins wrote:
If it works, I say commit the patch. Can think of no reason why we
should not cache an URL ending is /.
Because the cache_in filter gets added in the quick_handler. The
fast_internal_redirect in mod_dir
On Thu, 15 Jul 2004 18:32:04 -0700, Stas Bekman [EMAIL PROTECTED] wrote:
Does anybody use that function? I can't see any uses of it in the core
code. If not, shouldn't it be removed?
I found a description of its use in a 1.3 module at
http://www.kuzbass.ru:8086/docs/apache_c_mod_perl/164.htm
At 09:13 AM 7/16/2004, Graham Leggett wrote:
Brian Akins wrote:
Because the cache_in filter gets added in the quick_handler. The
fast_internal_redirect in mod_dir which translates / to /index.html (or whatever)
seems to lose this filter, so it never gets cached.
Then I'd say the fix should be
* William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
At 09:13 AM 7/16/2004, Graham Leggett wrote:
Brian Akins wrote:
Because the cache_in filter gets added in the quick_handler. The
fast_internal_redirect in mod_dir which translates / to /index.html (or
whatever) seems to lose this filter, so
[Forwarding on behalf of Tair-Shian Chou who has problems getting his
mail through to [EMAIL PROTECTED] list]
-Madhu
-Original Message-
From: Tair-Shian Chou [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 15, 2004 3:10 PM
To: '[EMAIL PROTECTED]'
Subject: FW: Bug in AuthLDAPURL?
Hi
I'm pleased to invite all interested members of the httpd community
to participate in the incubation of a new httpd subproject, cli-dev.
An immediate and initial benefit of this subproject is a donation of
code I created at Covalent to host ASP.NET content within httpd 2.0,
strictly for the MS
This does work according to what the documentation says but you must
surround the LDAP URL with double quote as Graham suggested
AuthLDAPURL ldap://ldap1.airius.com
ldap2.airius.com/ou=People,o=Airius
Otherwise Apache will interpret the space between the host names to be
two different
/**
* Install a custom response handler for a given status
* @param r The current request
* @param status The status for which the custom response should be used
* @param string The custom response. This can be a static string, a file
* or a URL
*/
AP_DECLARE(void)
Yes, it works. I thought I tried with double quotes. My mistake.
Thanks,
Chou
-Original Message-
From: Brad Nicholes [mailto:[EMAIL PROTECTED]
Sent: Friday, July 16, 2004 3:59 PM
To: MATHIHALLI,MADHUSUDAN (HP-Cupertino); [EMAIL PROTECTED]
Subject: Re: FW: Bug in AuthLDAPURL?
Pier Fumagalli wrote:
I don't understand why mod_cache forcedly avoids caching URLs ending
with the / (slash) character.
Apparently EGP (who's he?) agrees.
Anyhow, it's several months that we're running with this patch in
production, and nothing bad seems to be happening.
Pier
diff -U3 -wr
/**
* Implements condition GET rules for HTTP/1.1 specification. This
function
* inspects the client headers and determines if the response fulfills
* the requirements specified.
* @param r The current request
* @return 1 if the response fulfills the condition GET rules, 0 otherwise
*
31 matches
Mail list logo
