[Graham Leggett:]
| It would be nice to have different modules for reverse proxy and forward
| proxy.. from an FTP perspective.
|
| There is a fairly large difference in FTP (and perhaps in other protocols
| too) in terms of the optimizations that needs to be done for forward proxy
| and
[Graham Leggett:]
| It would be nice to have different modules for reverse proxy and forward
| proxy.. from an FTP perspective.
|
| There is a fairly large difference in FTP (and perhaps in other protocols
| too) in terms of the optimizations that needs to be done for forward proxy
| and
On Thu, October 11, 2007 12:53 pm, rahul wrote:
True, my point is that these choices are distributed all over the code.
While it can certainly be run together, it would be much cleaner to have
different modules with emphasis on different things while using a common
ftp_util base for things
[Graham Leggett:]
| True, my point is that these choices are distributed all over the code.
| While it can certainly be run together, it would be much cleaner to have
| different modules with emphasis on different things while using a common
| ftp_util base for things that are similar.
| The
On Thu, October 11, 2007 2:41 pm, rahul wrote:
In the case of a forward proxy you cant expect to get any of these
information from the configuration. So you start with the most general
assumption, and if it fails, you try the next one by interrogating the
server. The requirement of highest
On Wed, October 10, 2007 3:27 pm, rahul wrote:
It would be nice to have different modules for reverse proxy and forward
proxy.. from an FTP perspective.
There is a fairly large difference in FTP (and perhaps in other protocols
too) in terms of the optimizations that needs to be done for
On 10/8/07 1:44 PM, Roy T. Fielding [EMAIL PROTECTED] wrote:
For the millionth time, if that is a problem then separate the proxy
module from the gateway (reverse proxy) module. They do not belong
together.
+1. This would sway me more to go back to the stock modules. The
reverse proxy
Akins, Brian wrote:
For the millionth time, if that is a problem then separate the proxy
module from the gateway (reverse proxy) module. They do not belong
together.
+1. This would sway me more to go back to the stock modules. The
reverse proxy could be much more aggressive with
On Wed, 10 Oct 2007 00:17:18 +0200
Graham Leggett [EMAIL PROTECTED] wrote:
As I recall there is very little difference between the code for
forward proxy and the code for reverse proxy, the key differences
being to send a Proxy-Auth instead of Auth where appropriate, and
other minor things.
On 10/08/2007 12:50 AM, Nick Kew wrote:
On Thu, 13 Sep 2007 08:47:13 -0700
Roy T. Fielding [EMAIL PROTECTED] wrote:
Proxies are absolutely
forbidden from making any change to the URI -- they must forward
as is or return an error.
This is at the root of PR41798, and the others I've
On Mon, 08 Oct 2007 11:17:23 +0200
Ruediger Pluem [EMAIL PROTECTED] wrote:
Please check that your patch does not fall into the traps I mentioned
in
http://mail-archives.apache.org/mod_mbox/httpd-dev/200709.mbox/[EMAIL
PROTECTED]
Yesterday's discovery that suddenly makes this look easy,
On Oct 8, 2007, at 2:17 AM, Ruediger Pluem wrote:
Please check that your patch does not fall into the traps I
mentioned in
http://mail-archives.apache.org/mod_mbox/httpd-dev/200709.mbox/%
[EMAIL PROTECTED]
on this thread. Otherwise we create a security issue (at least for
reverse proxies
On Thu, 13 Sep 2007 08:47:13 -0700
Roy T. Fielding [EMAIL PROTECTED] wrote:
Proxies are absolutely
forbidden from making any change to the URI -- they must forward
as is or return an error.
This is at the root of PR41798, and the others I've marked as
duplicates of it.
In fact, it seems
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 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 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.
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) show a history of incorrect URL-unescaping in mod_proxy.
For PR41798, the attached patch looks like a fix: it just uses
r-unparsed_uri (escaped) instead of r-uri
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) show a history of incorrect URL-unescaping in
mod_proxy.
For PR41798, the attached
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) show a history of incorrect URL-unescaping in
On Sun, 09 Sep 2007 22:00:25 +0200
Ruediger Pluem [EMAIL PROTECTED] wrote:
[chop]
Thanks for the analysis. It's the insights I was looking for
together with some points I'd argue. But I need to give it more
think-time before proposing a revised patch.
--
Nick Kew
Application Development
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.
For PR41798, the attached patch looks like a fix: it just uses
r-unparsed_uri (escaped) instead of r-uri (unescaped) in
proxy_trans. I'm wondering if using
26 matches
Mail list logo
