Brad Nicholes said:
The attached patches convert LDAPTrustedMode into a per-directory
directive rather than a per-server. This allows the configuration to
specify which mode should be applied for the associated AuthLDAPURL.
Thoughts on whether this should be the way to go or if
I presume this fixes #31418? Your patch makes sense to me. I could
argue that it could even be done *before* the SSLRequire checking, such
that the username is logged appropriately even if an SSLRequire
triggers a 403, but I doubt that matters much.
Thanks for looking at this!
William A. Rowe, Jr. wrote:
My only concern ... does this new scope pair up properly if the
user cert has been renegotiated? If so +1
I'm unable to test that here, but maybe if someone has a system where
renegotiation is testable...
david
Bill
At 07:17 PM 2/1/2005, you wrote:
Index:
On Wed, Feb 02, 2005 at 10:07:56AM +, David Reid wrote:
William A. Rowe, Jr. wrote:
My only concern ... does this new scope pair up properly if the
user cert has been renegotiated? If so +1
I'm unable to test that here, but maybe if someone has a system where
renegotiation is
Basically this allows us to gain access to the actual cert structure.
Index: ssl_engine_vars.c
===
--- ssl_engine_vars.c (revision 123890)
+++ ssl_engine_vars.c (working copy)
@@ -364,6 +364,10 @@
else if (strcEQ(var, CERT))
On Wed, Feb 02, 2005 at 10:17:04AM +, David Reid wrote:
Basically this allows us to gain access to the actual cert structure.
I don't like the idea of exposing the X509 * directly especially not
through a char * interface. Exposing the DER representation (e.g.
base64-encoded) through
Justin Erenkrantz wrote:
--On Wednesday, February 2, 2005 12:25 AM +1100 dean
[EMAIL PROTECTED] wrote:
My first thought was that Firefox has an issue. Then I installed 2.0.53
as a cache-proxy BUT I couldn't reproduce the above, Google logo loads
everytime.
Another simple page I tried is
Joe Orton wrote:
On Wed, Feb 02, 2005 at 10:17:04AM +, David Reid wrote:
Basically this allows us to gain access to the actual cert structure.
I don't like the idea of exposing the X509 * directly especially not
through a char * interface. Exposing the DER representation (e.g.
On Wed, Feb 02, 2005 at 11:09:47AM +, David Reid wrote:
Joe Orton wrote:
On Wed, Feb 02, 2005 at 10:17:04AM +, David Reid wrote:
Basically this allows us to gain access to the actual cert structure.
I don't like the idea of exposing the X509 * directly especially not
through a
Joe Orton wrote:
On Wed, Feb 02, 2005 at 11:09:47AM +, David Reid wrote:
Joe Orton wrote:
On Wed, Feb 02, 2005 at 10:17:04AM +, David Reid wrote:
Basically this allows us to gain access to the actual cert structure.
I don't like the idea of exposing the X509 * directly especially not
On Wed, Feb 02, 2005 at 11:36:41AM +, Ben Laurie wrote:
Joe Orton wrote:
On Wed, Feb 02, 2005 at 11:09:47AM +, David Reid wrote:
The issue is a need to get access to the internals of the structure.
By exposing the X509 * directly you expose a dependency on the
underlying SSL
+1
On Wed, 2 Feb 2005, Jim Jagielski wrote:
+1
Major +1 - though be aware of the fallout - internal redirects can play
nice heavoc.
DW.
Please review the proxy-reqbody branch for proposed improvements to
2.1-dev. There is a 2.0.x equivalent of the patch at
http://httpd.apache.org/~trawick/20proxyreqbody.txt.
Joe Orton wrote:
I presume this fixes #31418? Your patch makes sense to me. I could
argue that it could even be done *before* the SSLRequire checking, such
that the username is logged appropriately even if an SSLRequire
triggers a 403, but I doubt that matters much.
fwiw that's the route
There are now tests for both PR 32459 and PR 15207 in httpd-test's
t/modules/proxy.t; the former fails at the moment in 2.1 and the
latter
should fail instead if you flip the silly #define.
sorry - the PR 32459 test is in t/modules/rewrite.t not proxy.t
The below results in corrected behavior...
Please note that I'm not 100% happy, since the below hides
the meeting of isenc, or at least changes it... The real
fix is to also pass r-proxyreq (to determine type of
proxy request) as well as isenc, which should be renamed
something like forceenc to force the encoding
no matter what type of
Jeff Trawick wrote:
Please review the proxy-reqbody branch for proposed improvements to
2.1-dev. There is a 2.0.x equivalent of the patch at
http://httpd.apache.org/~trawick/20proxyreqbody.txt.
+1 (reviewed, not tested)
certainly an improvement over what we have today. The brains (decisions
On Thu, Feb 03, 2005 at 08:44:03AM +1100, dean wrote:
Im not sure where to find out the revision, but I checked out the src
from cvs just before my first post. I just did another update and
nothing has changed. Hope Im using the right command:
cvs checkout -d httpd-2.1 httpd-2.0
Oh. In
Does not include the required removal of the unused FIX_15207
code snippets...
Index: modules/proxy/proxy_ajp.c
===
--- modules/proxy/proxy_ajp.c (revision 149512)
+++ modules/proxy/proxy_ajp.c (working copy)
@@ -79,7 +79,7 @@
At 04:17 AM 2/2/2005, David Reid wrote:
Basically this allows us to gain access to the actual cert structure.
Agreed that raw cert isn't that useful, and somewhat frightens
me in the environment table. The PEM or DER formats would be
generally useful. Unpacking the extended X509 attributes
+1, allowing mod_authnz_ldap to override the default makes a lot more
sense. Unless you are already working on a patch, I will try to put
something together today. But after today I will be offline for the
next two days.
Brad
[EMAIL PROTECTED] Wednesday, February 02, 2005 1:23:51 AM
Brad
Brad Nicholes wrote:
+1, allowing mod_authnz_ldap to override the default makes a lot more
sense. Unless you are already working on a patch, I will try to put
something together today. But after today I will be offline for the
next two days.
I will only have a chance to work on this tomorrow :(
I was recently considering a similar patch for mod_proxy along the lines
of spool_reqbody_cl() method but it would go one step further: spawning
off a thread to asynchronously read the request into a temp file (or
files) while the initial thread would continue to stream the io_bufsize
chunks down
Ronald Park wrote:
I was recently considering a similar patch for mod_proxy along the lines
of spool_reqbody_cl() method but it would go one step further: spawning
off a thread to asynchronously read the request into a temp file (or
files) while the initial thread would continue to stream the
Hmm, don't know enough about Event MPM to comment on that part of the
message, but with regards to the performance for small requests, in my
original 'design' for this, I figured it would do one synchronous read
first, pass that through the filter chain and, if '(!seen_eos)', then
it would pay the
Paul Querna wrote:
One thought I have been tossing around for a long time is tying the
proxy code into the Event MPM. Instead of a thread blocking while it
waits for a backend reply, the backend server's FD would be added to the
Event Thread, and then when the reply is ready, any available
Imagine, just as a wild theoretical scenario (:D), that you have
the following setup:
Apache - (proxy) - Squid - (cache miss) - Apache - (docroot)
Where the back-end Apache serves up large files (in the 2G range)
(and, yes, there are far more files that can be effectively cached).
Now imagine
On Wed, 02 Feb 2005 12:32:39 -0500, Ronald Park [EMAIL PROTECTED] wrote:
I was recently considering a similar patch for mod_proxy along the lines
of spool_reqbody_cl() method but it would go one step further: spawning
off a thread to asynchronously read the request into a temp file (or
files)
Ron,
Who is trying to serve up 2GB files?
Peter J. Cranstone
-Original Message-
From: Ronald Park [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 02, 2005 11:24 AM
To: dev@httpd.apache.org
Subject: Re: Multi-threaded proxy? was Re: re-do of proxy request
bodyhandling - ready for
Any reason why we don't enable reporting of Req? I have
a 2.1 patch ready to go, but I don't know why we don't
do this
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
There 10 types of people:
True, the client and the proxying server are tied up intrinsically.
I used the wrong wording to name who would benefit. I meant that
the server providing the proxied content (the 'other' server; the
one not directly talking to the client) could be done and on it's
way doing other work while the
Peter J. Cranstone wrote:
Who is trying to serve up 2GB files?
Redhat's DVD images (just one example).
Regards,
Graham
--
smime.p7s
Description: S/MIME Cryptographic Signature
Ronald Park wrote:
I was recently considering a similar patch for mod_proxy along the lines
of spool_reqbody_cl() method but it would go one step further: spawning
off a thread to asynchronously read the request into a temp file (or
files) while the initial thread would continue to stream the
Ronald Park wrote:
In this picture:
C -- A -- P
C, the client, makes a request to A which proxies it to P. A P
can do their exchange independant of C A. If A-P can be done fast,
but C-A is slow, then P's wasting resource, no?
If you configured mod_cache, my understanding is that P would
On Wed, Feb 02, 2005 at 08:45:53PM +0200, Graham Leggett wrote:
Peter J. Cranstone wrote:
Who is trying to serve up 2GB files?
Redhat's DVD images (just one example).
Ahhh, and I was just about to pipe-up :) But for the record,
ftp.heanet.ie currently servers 23 distinct 2Gb files an
I have got something that almost works now. The problem that I am
running into is that util_ldap_connection_find() doesn't know the
difference between APR_LDAP_NONE(the secure mode was never set so use
the default) vs. APR_LDAP_NONE (NONE is what I really want). Seems like
we need another
Brad Nicholes wrote:
I have got something that almost works now. The problem that I am
running into is that util_ldap_connection_find() doesn't know the
difference between APR_LDAP_NONE(the secure mode was never set so use
the default) vs. APR_LDAP_NONE (NONE is what I really want). Seems
You read my mind. I'm all over it. :)
Brad
Graham Leggett [EMAIL PROTECTED] Wednesday, February 02, 2005
12:13:56 PM
Brad Nicholes wrote:
I have got something that almost works now. The problem that I
am
running into is that util_ldap_connection_find() doesn't know the
difference
--On Wednesday, February 2, 2005 1:43 PM -0500 Jim Jagielski
[EMAIL PROTECTED] wrote:
Any reason why we don't enable reporting of Req? I have
a 2.1 patch ready to go, but I don't know why we don't
do this
I have no earthly idea what you are talking about. =)
Can you please provide some more
--On Wednesday, February 2, 2005 8:49 PM +0200 Graham Leggett
[EMAIL PROTECTED] wrote:
Mod_cache already supports the concept of spooling files to disk (or
memory, or shared memory), and can be taught how to serve an incompletely
downloaded file to other clients (apparently it cannot at the
William A. Rowe, Jr. wrote:
At 04:17 AM 2/2/2005, David Reid wrote:
Basically this allows us to gain access to the actual cert structure.
Agreed that raw cert isn't that useful, and somewhat frightens
me in the environment table. The PEM or DER formats would be
generally useful. Unpacking the
On Wed, 02 Feb 2005 19:17:03 -, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Author: stoddard
Date: Wed Feb 2 11:17:02 2005
New Revision: 149548
URL: http://svn.apache.org/viewcvs?view=revrev=149548
Log:
yeow, Bill why didn't you propose this earlier?
*that's* the one I was telling you
Justin Erenkrantz wrote:
I don't understand the purpose of serving incomplete files from a cache.
Can you please elaborate on what you think mod_cache should do? -- justin
Since the early days of mod_proxy, there has been a race condition in
the caching code which has been carried over to
-Original Message-
From: Graham Leggett [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 02, 2005 10:39 PM
To: dev@httpd.apache.org
Subject: Re: re-do of proxy request body handling - ready for review
Justin Erenkrantz wrote:
I don't understand the purpose of serving
--On Wednesday, February 2, 2005 11:38 PM +0200 Graham Leggett
[EMAIL PROTECTED] wrote:
If mod_cache was taught to serve a being-cached URL directly from the
cache (shadowing the real download), there would be no need for parallel
connections to the backend server while the file is being cached,
At 03:28 PM 2/2/2005, Jeff Trawick wrote:
On Wed, 02 Feb 2005 19:17:03 -, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Author: stoddard
Date: Wed Feb 2 11:17:02 2005
New Revision: 149548
URL: http://svn.apache.org/viewcvs?view=revrev=149548
Log:
yeow, Bill why didn't you propose this
--On Wednesday, February 2, 2005 8:40 AM -0500 Jeff Trawick
[EMAIL PROTECTED] wrote:
Please review the proxy-reqbody branch for proposed improvements to
2.1-dev. There is a 2.0.x equivalent of the patch at
http://httpd.apache.org/~trawick/20proxyreqbody.txt.
To help people review Jeff's
Justin Erenkrantz wrote:
--On Wednesday, February 2, 2005 1:43 PM -0500 Jim Jagielski
[EMAIL PROTECTED] wrote:
Any reason why we don't enable reporting of Req? I have
a 2.1 patch ready to go, but I don't know why we don't
do this
I have no earthly idea what you are talking
Jim Jagielski wrote:
Justin Erenkrantz wrote:
--On Wednesday, February 2, 2005 1:43 PM -0500 Jim Jagielski
[EMAIL PROTECTED] wrote:
Any reason why we don't enable reporting of Req? I have
a 2.1 patch ready to go, but I don't know why we don't
do this
I have no earthly idea what you are
httpd-2.1/STATUS:
RELEASE SHOWSTOPPERS:
* the edge connection filter cannot be removed
http://marc.theaimsgroup.com/?l=apache-httpd-devm=105366252619530w=2
jerenkrantz asks: Why should this block a release?
because it requires a rewrite of the filters stack implementation (you
have suggested
Stas Bekman wrote:
Jim Jagielski wrote:
Justin Erenkrantz wrote:
--On Wednesday, February 2, 2005 1:43 PM -0500 Jim Jagielski
[EMAIL PROTECTED] wrote:
Any reason why we don't enable reporting of Req? I have
a 2.1 patch ready to go, but I don't know why we don't
do this
I
Jim Jagielski wrote:
Stas Bekman wrote:
Jim Jagielski wrote:
Justin Erenkrantz wrote:
--On Wednesday, February 2, 2005 1:43 PM -0500 Jim Jagielski
[EMAIL PROTECTED] wrote:
Any reason why we don't enable reporting of Req? I have
a 2.1 patch ready to go, but I don't know why we don't
do this
On Wed, Feb 02, 2005 at 11:11:15PM -0500, Stas Bekman wrote:
thanks Jim. and 3 +1s were added already. if it makes into 2.0.53 that
would be great.
If no one has beaten me to it, I plan to merge all changes with 3 +1s in
STATUS on Friday morning before I lay down the 2.0.53 tag. -- justin
Justin Erenkrantz wrote:
I don't see any way to implement that cleanly and without lots of undue
complexity. Many dragons lay in that direction.
When I put together the initial framework of mod_cache, solving this
problem was one of my goals.
How do we know when another worker has already
55 matches
Mail list logo
