> From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]]
> Sent: 21 September 2001 08:38
> From: "Sander Striker" <[EMAIL PROTECTED]>
> Sent: Thursday, September 13, 2001 7:30 AM
>
>
> > Ok, now I have a repro recipe that doesn't require
> > mod_dav and mod_dav_svn.
>
> The last commit should ha
From: "Sander Striker" <[EMAIL PROTECTED]>
Sent: Thursday, September 13, 2001 7:30 AM
> Ok, now I have a repro recipe that doesn't require
> mod_dav and mod_dav_svn.
The last commit should have fixed the problem (and does with
your mod_ssl example.) Could you go back and check mod_dav
with mod
From: "Sander Striker" <[EMAIL PROTECTED]>
Sent: Thursday, September 13, 2001 7:30 AM
> Ok, now I have a repro recipe that doesn't require
> mod_dav and mod_dav_svn.
Well, I took the easy way out, tried Doug's (using VirtualHost *)
and failed. Probably would have worked if I tried his _exact_
On Thu, 13 Sep 2001, Sander Striker wrote:
can also reproduce with less in the mix:
Listen 8999
#this can be any module with per-directory create+merge functions
RequestHeader add Foo bar
Order deny,allow
Deny from all
Allow from 127.0.0.1
0x40246225 i
Ok, now I have a repro recipe that doesn't require
mod_dav and mod_dav_svn.
Try this in httpd.conf:
SSLEngine on
SSLCACertificatePath /var/openssl/ca/private
SSLCACertificateFile /var/openssl/ca/private/ca.cert
SSLCertificateFile /var/openssl/ca/certs/striker.xs4all.nl.cert
Hi,
I can reproduce the problem easily now with
openssl s_client. If anyone is interested
to hunt this bug down (I am personally not
familiar enough with the location_walk code
to find it (without spending more time on
it than I have at the moment)), I can give
an account on my box to observe th
> From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]]
> My location_walk optimization (which suffers a potential bug, per
> our svn friends) takes an entirely different tact, which renders
> that whole idea DOA.
Ok, to rule out the possibility it is in the optimization code
I reverted to reque
