On Wed, 28 Apr 2004 17:17:16 -0700
Justin Erenkrantz [EMAIL PROTECTED] wrote:
--On Thursday, April 15, 2004 12:22 PM +0200 Jacek Prucia
[EMAIL PROTECTED] wrote:
I have just commited a fix to manual. However, I do not have enough
karma to put manual on flood page, so we need a config file
Really nifty flood feature is the ability to initialize variable to
random value. Using following construct: ${=name} inside
requesttemplate causes flood to create variable 'name', and assign it
a value obtained by calling rand/lrand48/random. Consider a typical
scenario, where you would like to
A friend has suggested that you might want to consider
allowing ${name=rand(41)} as a construct similar to :41?
Guy
-Original Message-
From: Jacek Prucia [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 12, 2004 9:37 AM
To: [EMAIL PROTECTED]
Subject: fixed range for random variables
When using Apache as a proxy:
( brower --https-- Apache + mod_proxy --https-- Web server )
the Web server never receives the user's certificate info, because only the
proxy is seen by the Web server. That means that all headers SSL_CLIENT_*
contain the proxy certificate info, not the user
Brad Nicholes wrote:
Before using known values, it should
look for the port in the connection information (ie.
r-connection-local_addr-port). The current result can produce
incorrect port information when a port value is not supplied as part of
the URL. According to the documentation, if
On Mon, May 10, 2004 at 11:02:21AM -0400, Brian Akins wrote:
Any reason why expires set by mod_expires are not added to redirected
requests? Should I hack up my own expires that does?
Are you using 2.0.49? There's a fix for setting Expires on error
responses in that version, it seems to work
On Wed, May 12, 2004 at 01:09:03PM +0200, Marc Stern wrote:
When using Apache as a proxy:
( brower --https-- Apache + mod_proxy --https-- Web server )
the Web server never receives the user's certificate info, because only the
proxy is seen by the Web server. That means that all headers
On May 11, 2004, at 6:18 PM, Brad Nicholes wrote:
+1 to Bill's comment. I don't quite understand what is confusing and
why we would need UseCanonicalPort. IMO, all that really needs to be
done is to fix UseCanonicalName so that it works according to the
documentation. As was explained
Joe Orton wrote:
On Mon, May 10, 2004 at 11:02:21AM -0400, Brian Akins wrote:
Any reason why expires set by mod_expires are not added to redirected
requests? Should I hack up my own expires that does?
Are you using 2.0.49? There's a fix for setting Expires on error
responses in that
On May 11, 2004, at 9:53 PM, Jim Jagielski wrote:
IMO, we need more control over the port number that Apache
determines to be canonical beyond that which is provided
by UseCanonicalName, simply because there are so
many options and permutations which are possible
and applicable for different
Now I understand better, thanks. The issue that prompted me to
implement the fixes for 2.1 and 1.3 manifested themselves primarily on
NetWare due to the way NetWare implements the SSL functionality (NetWare
doesn't use mod_ssl). In some cases requrests on an SSL port were being
redirected to
Do you mean that 2.0 now works correctly? In that case
maybe the short-term is to use the 2.0 method for both
1.3 and 2.1, until we can figure out a better
method... I think the 2.0 method is likely more
correct than the 1.3/2.1 one, at least as a default
implementation.
On May 12, 2004, at 1:13
It works correctly for the NetWare SSL case that I was running into.
But I don't think it works correctly for the case that you are
describing. The patches that I added to 2.0 and 1.3 are NetWare
specific. The 2.0 patch is in mod_nw_ssl.c which implements the
default_port hook and the 1.3 patch
What I've done, for the 1.3 case, is make honoring the
physical port number (ala 2.1) a compile-time flag...
This should hold us off until we figure out a better
way to do this, so it may get backed out when
that happens. In the meantime, 1.3.32-dev will
operate as does 2.0, which is, I think, the
I guess the part that confuses me most is why is honoring the physical
port number a bad thing? If you look at the implementation of
ap_get_server_port() in the 2.0 branch, the function determines the port
value by:
USE_CANONICAL_NAME_OFF || USE_CANONICAL_NAME_DNS
1- parsed_uri.port
2-
* Jim Jagielski [EMAIL PROTECTED] wrote:
I'd like to propose that the apache-1.3 tree be migrated over
to subversion.
I'm +1 on it.
nd
--
Real programmers confuse Christmas and Halloween because
DEC 25 = OCT 31. -- Unknown
(found in ssl_engine_mutex.c)
Well, at least with 2.0, that's the way ServerName is
documented...
nd is right... the actual physical port can never be, afaik, 0,
so wherever that is in the logic path, that's the final end :)
But on thinking it even more deeply, having Apache return
the physical port can always be done via
I'm not sure that I understand what the problem is. By updating the
binddn/bindpw in the connection record, we always know exactly which
userid the connection is bound to. During the
util_ldap_connection_find() routine there are two searches performed.
The first search looks for a connection
-Original Message-
From: Joe Orton [mailto:[EMAIL PROTECTED]
Sent: Friday, April 30, 2004 3:08 AM
Looks fine, though it doesn't handle errors in apr_atoi64
itself so it would be good to surround the calls with a single
errno = 0 / ... /
if (errno) return -1; check too.
It seems
Brad,
Your patch fix the flaw I talk about in my two previous e-mails. (Do not
forget the main trunk which has the same flaw.)
I agree with all you said, except that my patch (Bug 27134) do not make
unnecessary rebind. The main difference between your solution and mine
is that I delegate the
--On Thursday, May 13, 2004 1:02 AM +0200 Denis Gervalle [EMAIL PROTECTED]
wrote:
Your patch fix the flaw I talk about in my two previous e-mails. (Do not
forget the main trunk which has the same flaw.)
I agree with all you said, except that my patch (Bug 27134) do not make
unnecessary rebind.
APACHE 1.3 STATUS: -*-text-*-
Last modified at [$Date: 2004/05/07 14:43:04 $]
Release:
1.3.32-dev: In development
1.3.31: Tagged May 7, 2004.
1.3.30: Tagged April 9, 2004. Not released.
1.3.29: Tagged October 24, 2003. Announced Oct 29,
APACHE 1.3 STATUS: -*-text-*-
Last modified at [$Date: 2004/05/07 14:43:04 $]
Release:
1.3.32-dev: In development
1.3.31: Tagged May 7, 2004.
1.3.30: Tagged April 9, 2004. Not released.
1.3.29: Tagged October 24, 2003. Announced Oct 29,
APACHE 2.0 STATUS: -*-text-*-
Last modified at [$Date: 2004/05/13 00:16:43 $]
Release:
2.0.50 : in development
2.0.49 : released March 19, 2004 as GA.
2.0.48 : released October 29, 2003 as GA.
2.0.47 : released July 09, 2003 as GA.
APACHE 2.1 STATUS: -*-text-*-
Last modified at [$Date: 2004/04/27 22:09:17 $]
Release [NOTE that only Alpha/Beta releases occur in 2.1 development]:
2.1.0 : in development
Please consult the following STATUS files for information
on related
APACHE 2.0 STATUS: -*-text-*-
Last modified at [$Date: 2004/05/13 00:16:43 $]
Release:
2.0.50 : in development
2.0.49 : released March 19, 2004 as GA.
2.0.48 : released October 29, 2003 as GA.
2.0.47 : released July 09, 2003 as GA.
APACHE 2.1 STATUS: -*-text-*-
Last modified at [$Date: 2004/04/27 22:09:17 $]
Release [NOTE that only Alpha/Beta releases occur in 2.1 development]:
2.1.0 : in development
Please consult the following STATUS files for information
on related
27 matches
Mail list logo
