On Fri, Sep 07, 2007 at 02:59:10PM -0500, William Rowe wrote:
FYI - this bug appears to be the root of several modules no longer
behaving as expected on Win32 platforms.
It takes me back to a question I raised on apr quite a while ago,
what does *unix* do with an unset
Joe Orton wrote:
On Fri, Sep 07, 2007 at 02:59:10PM -0500, William Rowe wrote:
FYI - this bug appears to be the root of several modules no longer
behaving as expected on Win32 platforms.
It takes me back to a question I raised on apr quite a while ago,
what does *unix* do with an unset
On Wed, Sep 12, 2007 at 10:47:03AM -, William Rowe wrote:
Author: wrowe
Date: Wed Sep 12 03:47:02 2007
New Revision: 574884
URL: http://svn.apache.org/viewvc?rev=574884view=rev
Log:
Resolve storage of process-lifespan version strings for OpenSSL,
while using request-lifespan copies
Joe Orton wrote:
On Wed, Sep 12, 2007 at 10:47:03AM -, William Rowe wrote:
Author: wrowe
Date: Wed Sep 12 03:47:02 2007
New Revision: 574884
URL: http://svn.apache.org/viewvc?rev=574884view=rev
Log:
Resolve storage of process-lifespan version strings for OpenSSL,
while using
William A. Rowe, Jr. wrote:
Joe Orton wrote:
Ewww. This passes around a process-global pool to functions which can
get invoked at any time during request processing, which just invites a
thread-safety fubar down the line. It only happens to be safe now
because the function is invoked at
On Sun, 9 Sep 2007 01:21:29 +0100
Nick Kew [EMAIL PROTECTED] wrote:
PR 41798 and many related ones (eg 39746, 38980 - both of which I've
closed today) show a history of incorrect URL-unescaping in mod_proxy.
Since then I've found several more duplicates in bugzilla.
Furthermore, it's not
Joe Orton wrote:
On Mon, Sep 10, 2007 at 09:47:24PM +0200, Ruediger Pluem wrote:
On 09/10/2007 08:40 AM, Plüm wrote:
That was the goal of my diagnostic patch: Finding out if we have a pool
issue. Looks like we have. I guess the right fix is as you say
to use the parent pool (process scope).
On Sep 9, 2007, at 1:00 PM, Ruediger Pluem wrote:
On 09/09/2007 04:30 PM, Nick Kew wrote:
On Sun, 09 Sep 2007 11:25:26 +0200
Ruediger Pluem [EMAIL PROTECTED] wrote:
On 09/09/2007 02:21 AM, Nick Kew wrote:
PR 41798 and many related ones (eg 39746, 38980 - both of which
I've
closed today)
-Ursprüngliche Nachricht-
Von: Roy T. Fielding
Gesendet: Donnerstag, 13. September 2007 16:45
An: dev@httpd.apache.org
Betreff: Re: Broken URI-unescaping in mod_proxy
On Sep 9, 2007, at 1:00 PM, Ruediger Pluem wrote:
On 09/09/2007 04:30 PM, Nick Kew wrote:
How so?
On Sep 13, 2007, at 7:54 AM, Plüm, Rüdiger, VF-Group wrote:
Changes to the request URI must be referred back to the client in the
form of a redirect. Any other choice will cause security holes in
the request chain, somewhere.
The proxy (when acting as a proxy) must not change the URI.
The
-Ursprüngliche Nachricht-
Von: Roy T. Fielding
Gesendet: Donnerstag, 13. September 2007 17:06
An: dev@httpd.apache.org
Betreff: Re: Broken URI-unescaping in mod_proxy
On Sep 13, 2007, at 7:54 AM, Plüm, Rüdiger, VF-Group wrote:
Changes to the request URI must be referred back
On Sep 13, 2007, at 8:20 AM, Plüm, Rüdiger, VF-Group wrote:
Sorry for being confused, but what change to a URI are you
talking about? Transforming
GET /a/../b/somewhere
into
a request for /b/somewhere?
This is the usual transformation we do also in the case we deliver
static content (without
On 11.09.2007, at 19:26, Jim Jagielski wrote:
On Sep 11, 2007, at 1:11 PM, Jeff McAdams wrote:
For the benefit of the list...if there are other developers, in
addition
to Nick, that might be interested in taking a look at this project
and
tackling it, let me know and we can certainly
On Sep 13, 2007, at 12:11 PM, Erik Abele wrote:
On 11.09.2007, at 19:26, Jim Jagielski wrote:
On Sep 11, 2007, at 1:11 PM, Jeff McAdams wrote:
For the benefit of the list...if there are other developers, in
addition
to Nick, that might be interested in taking a look at this
project and
On Thu, 13 Sep 2007 07:45:06 -0700
Roy T. Fielding [EMAIL PROTECTED] wrote:
Changes to the request URI must be referred back to the client in the
form of a redirect. Any other choice will cause security holes in
the request chain, somewhere.
Mapping URLs internally is the server's business.
On 13.09.2007, at 18:27, Jim Jagielski wrote:
On Sep 13, 2007, at 12:11 PM, Erik Abele wrote:
On 11.09.2007, at 19:26, Jim Jagielski wrote:
...
I actually work for a company which is currently working
out the logistics of open sourcing and donating our
SNMP module. It would serve as a nice
On 09/13/2007 05:47 PM, Roy T. Fielding wrote:
On Sep 13, 2007, at 8:20 AM, Plüm, Rüdiger, VF-Group wrote:
Sorry for being confused, but what change to a URI are you
talking about? Transforming
GET /a/../b/somewhere
into
a request for /b/somewhere?
This is the usual transformation we
On Sep 13, 2007, at 12:30 PM, Nick Kew wrote:
On Thu, 13 Sep 2007 07:45:06 -0700
Roy T. Fielding [EMAIL PROTECTED] wrote:
Changes to the request URI must be referred back to the client in the
form of a redirect. Any other choice will cause security holes in
the request chain, somewhere.
18 matches
Mail list logo
