Patch to mod_proxy for fixed reverse mapping support

This is a multi-part message in MIME format.
--------------602A59ACBD86B39B01DB1037
Content-Type: multipart/alternative;
boundary="------------316AD6FC050DE2639C278E4A"

--------------316AD6FC050DE2639C278E4A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

First of all, I would like to introduce myself. My name is
Martijn Schoemaker and I so programming/systemadmin/everything
*nix as my daytime job.

I am currently working at a big customer with a pretty complex
(too complex imho) proxy environment. This constists of
netscape proxies, ssl accelerators, netcache appliances, layer-4
switched and ofcourse apache proxies. In this environment we
use https at the frontend which is 'converted' to http requests
on the inside which are handled by the apache proxies. The problem
is that mod_proxy (as in apache 1.3.26) cannot reverse map to
urls outside it's own apache configuration. Because at different
places after the proxy, redirects are sent which need to be
rewritten to : https://fontend-address.com/<things> but because
mod_proxy uses the apache URL construction routines is not
possible (it will always map to http://<ServerName>/<rest>).

For this to be possible I created a small patch which does a
check on the 'fake' url if it contains a '://' and if so it
will use that as the first part and only pastes the additional
uri to that. If not, it just uses the apache url construction
routine as its default.

i.e. instead of a mapping like:
ProxyPassReverse /app/ http://internal-host:567/app

which will map to : http://<ServerName>/app/
it uses :

ProxyPassReverse https://frontend-address/app/
http://internal-host:567/app

which will map to the fixed URL supplied (the first part that is)

My question to you all is : am I making sense ? Can this be
incorporated in future releases ? As far as I can see this is
only added value and no other fake url will contain '://' unless
it is meant as fixed anyway.

I'd greatly appreciate any comments :)

Greetings,
Martijn Schoemaker

--
------ WARNING: This signature contains a VIRUS ! -------
- SHLRUIOHUIOWHLNNMSKHKDLWINDOWSJHFHKJLLUIHEKJLNDHKKJHL -
---------------------------------------------------------

--------------316AD6FC050DE2639C278E4A
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi,
First of all, I would like to introduce myself. My name is
 Martijn Schoemaker and I so programming/systemadmin/everything
 *nix as my daytime job.
I am currently working at a big customer with a pretty complex
 (too complex imho) proxy environment. This constists of
 netscape proxies, ssl accelerators, netcache appliances, layer-4
 switched and ofcourse apache proxies. In this environment we
 use https at the frontend which is 'converted' to http requests
 on the inside which are handled by the apache proxies. The problem
 is that mod_proxy (as in apache 1.3.26) cannot reverse map to
 urls outside it's own apache configuration. Because at different
 places after the proxy, redirects are sent which need to be
 rewritten to : <A HREF="https://fontend-address.com/">https://fontend-address.com/</A><things> but because
 mod_proxy uses the apache URL construction routines is not
 possible (it will always map to <A HREF="http://">http://</A><ServerName>/<rest>).
For this to be possible I created a small patch which does a
 check on the 'fake' url if it contains a '://' and if so it
 will use that as the first part and only pastes the additional
 uri to that. If not, it just uses the apache url construction
 routine as its default.
i.e. instead of a mapping like:
 ProxyPassReverse /app/ <A HREF="http://internal-host:567/app">http://internal-host:567/app</A>
which will map to : <A HREF="http://">http://</A><ServerName>/app/
 it uses :
ProxyPassReverse <A HREF="https://frontend-address/app/">https://frontend-address/app/</A> <A HREF="http://internal-host:567/app">http://internal-host:567/app</A>
which will map to the fixed URL supplied (the first part that is)
My question to you all is : am I making sense ? Can this be
 incorporated in future releases ? As far as I can see this is
 only added value and no other fake url will contain '://' unless
 it is meant as fixed anyway.
I'd greatly appreciate any comments :)
Greetings,
 Martijn Schoemaker
 
<pre>--
------ WARNING: This signature contains a VIRUS ! -------
- SHLRUIOHUIOWHLNNMSKHKDLWINDOWSJHFHKJLLUIHEKJLNDHKKJHL -
---------------------------------------------------------</pre>
</html>

--------------316AD6FC050DE2639C278E4A--

--------------602A59ACBD86B39B01DB1037
Content-Type: text/plain; charset=us-ascii;
name="full_revproxy.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="full_revproxy.patch"

*** proxy_http.c.orig Thu Jul 25 17:23:00 2002
--- proxy_http.c Fri Jul 26 13:38:59 2002
***************
*** 129,139 ****
ent = (struct proxy_alias *)conf->raliases->elts;
for (i = 0; i < conf->raliases->nelts; i++) {
l2 = strlen(ent[i].real);
if (l1 >= l2 && strncmp(ent[i].real, url, l2) == 0) {
u = ap_pstrcat(r->pool, ent[i].fake, &url[l2], NULL);
! return ap_construct_url(r->pool, u, r);
}
}
return url;
}

--- 129,146 ----
ent = (struct proxy_alias *)conf->raliases->elts;
for (i = 0; i < conf->raliases->nelts; i++) {
l2 = strlen(ent[i].real);
if (l1 >= l2 && strncmp(ent[i].real, url, l2) == 0) {
u = ap_pstrcat(r->pool, ent[i].fake, &url[l2], NULL);
! /* If a :// is in the fake URL (i.e to be reversed URL)
! * we trust that the fake is a complete URL and we pass
! * it as-is. This allows reverse mapping for other hosts
! * that are upwards in the proxy-chain.
! */
! if (strstr(ent[i].fake, "://"))
! return u;
! else return ap_construct_url(r->pool, u, r);
}
}
return url;
}

--------------602A59ACBD86B39B01DB1037--

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2371F.9C865B80
Content-Type: text/plain

This patch makes a lot of sense. This would be very useful to my
organization. I hope it's seriously considered for incorporation in future
mod_proxy releases.

We had implemented a configuration workaround:

ProxyPassReverse /cgi-bin/redir?http://externalhost:777/yadda/
http://internalhost:999/yadda/

....that works, but using CGI is less than ideal. There's probably a slightly
better way to do this with mod_rewrite, but patching ProxyPassReverse to be
more versatile is hands-down the best solution.

-----Original Message-----
From: Martijn Schoemaker [mailto:martijn [at] osp.nl]
Sent: Monday, July 29, 2002 8:38 AM
To: modproxy-dev [at] apache.org
Subject: Patch to mod_proxy for fixed reverse mapping support

Hi,
First of all, I would like to introduce myself. My name is
Martijn Schoemaker and I so programming/systemadmin/everything
*nix as my daytime job.
I am currently working at a big customer with a pretty complex
(too complex imho) proxy environment. This constists of
netscape proxies, ssl accelerators, netcache appliances, layer-4
switched and ofcourse apache proxies. In this environment we
use https at the frontend which is 'converted' to http requests
on the inside which are handled by the apache proxies. The problem
is that mod_proxy (as in apache 1.3.26) cannot reverse map to
urls outside it's own apache configuration. Because at different
places after the proxy, redirects are sent which need to be
rewritten to : https://fontend-address.com/ <https://fontend-address.com/>
<things> but because
mod_proxy uses the apache URL construction routines is not
possible (it will always map to http:// <http://> <ServerName>/<rest>).
For this to be possible I created a small patch which does a
check on the 'fake' url if it contains a '://' and if so it
will use that as the first part and only pastes the additional
uri to that. If not, it just uses the apache url construction
routine as its default.
i.e. instead of a mapping like:
ProxyPassReverse /app/ http://internal-host:567/app
<http://internal-host:567/app>
which will map to : http:// <http://> <ServerName>/app/
it uses :
ProxyPassReverse https://frontend-address/app/
<https://frontend-address/app/> http://internal-host:567/app
<http://internal-host:567/app>
which will map to the fixed URL supplied (the first part that is)
My question to you all is : am I making sense ? Can this be
incorporated in future releases ? As far as I can see this is
only added value and no other fake url will contain '://' unless
it is meant as fixed anyway.
I'd greatly appreciate any comments :)
Greetings,
Martijn Schoemaker

--
------ WARNING: This signature contains a VIRUS ! -------
- SHLRUIOHUIOWHLNNMSKHKDLWINDOWSJHFHKJLLUIHEKJLNDHKKJHL -
---------------------------------------------------------

------_=_NextPart_001_01C2371F.9C865B80
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">

<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"cid:filelist.xml [at] 01C236FE.163AA390">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
name=3D"time"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
name=3D"date"/>

<style>

</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dblue =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

This patch makes a lot of sense. =
This would
be very useful to my organization. I hope it's seriously considered for =
incorporation
in future mod_proxy =
releases.<o:p></o:p>

<o:p> </o:p>=

We had implemented a configuration
workaround:<o:p></o:p>

<o:p> </o:p>=

ProxyPassReverse =
/cgi-bin/redir?http://externalhost:777/yadda/ =
http://internalhost:999/yadda/<o:p></o:p>

<o:p> </o:p>=

...that works, but using CGI is =
less
than ideal. There's probably a slightly better way to do this with =
mod_rewrite, but patching ProxyPassReverse
to be more versatile is hands-down the best =
solution.<o:p></o:p>

<o:p> </o:p>=

-----Original =
Message----- 
From: Martijn Schoemaker
[mailto:martijn [at] osp.nl] 
Sent: <st1:date =
Month=3D"7" Day=3D"29"
Year=3D"2002">Monday, July 29, 2002</st1:date> =
<st1:time
Hour=3D"8" Minute=3D"38">8:38 AM</st1:time> 
To: =
modproxy-dev [at] apache.org 
Subject: Patch to =
mod_proxy for
fixed reverse mapping support

<o:p> </o:p>

Hi, <o:p></o:p>

First of all, I would like to introduce =
myself. My
name is 
Martijn Schoemaker and I so programming/systemadmin/everything 
*nix as my daytime job. <o:p></o:p>

I am currently working at a big customer =
with a pretty
complex 
(too complex imho) proxy environment. This constists of 
netscape proxies, ssl accelerators, netcache appliances, layer-4 
switched and ofcourse apache proxies. In this environment we 
use https at the frontend which is 'converted' to http requests 
on the inside which are handled by the apache proxies. The problem 
is that mod_proxy (as in apache 1.3.26) cannot reverse map to 
urls outside it's own apache configuration. Because at different 
places after the proxy, redirects are sent which need to be 
rewritten to : <a =
href=3D"https://fontend-address.com/">https://fontend-addres s.com/</a>&l=
t;things>
but because 
mod_proxy uses the apache URL construction routines is not 
possible (it will always map to <a =
href=3D"http://">http://</a><ServerName>/<rest>).
<o:p></o:p>

For this to be possible I created a small =
patch which
does a 
check on the 'fake' url if it contains a '://' and if so it 
will use that as the first part and only pastes the additional 
uri to that. If not, it just uses the apache url construction 
routine as its default. <o:p></o:p>

i.e. instead of a mapping like: 
ProxyPassReverse /app/ <a =
href=3D"http://internal-host:567/app">http://internal-host:5 67/app</a>
<o:p></o:p>

which will map to : <a =
href=3D"http://">http://</a><ServerName>/app/
 
it uses : <o:p></o:p>

ProxyPassReverse <a
href=3D"https://frontend-address/app/">https://frontend-addr ess/app/</a>=
<a
href=3D"http://internal-host:567/app">http://internal-host:5 67/app</a> =
<o:p></o:p>

which will map to the fixed URL supplied =
(the first
part that is) <o:p></o:p>

My question to you all is : am I making =
sense
? Can this be 
incorporated in future releases ? As far as I can see this is 
only added value and no other fake url will contain '://' unless 
it is meant as fixed anyway. <o:p></o:p>

I'd greatly appreciate any comments :) =
<o:p></o:p>

Greetings, 
Martijn Schoemaker 
<o:p></o:p>

<pre style=3D'margin-left:.5in'>-- <o:p></o:p></pre><pre
style=3D'margin-left:.5in'>------ WARNING: This signature contains a =
VIRUS ! -------<o:p></o:p></pre><pre
style=3D'margin-left:.5in'>- =
SHLRUIOHUIOWHLNNMSKHKDLWINDOWSJHFHKJLLUIHEKJLNDHKKJHL =
-<o:p></o:p></pre><pre
style=3D'margin-left:.5in'>--------------------------------- ------------=
------------<o:p></o:p></pre>

 <o:p></o:p>

</div>

</body>

</html>

------_=_NextPart_001_01C2371F.9C865B80--

Martijn Schoemaker wrote:

> i.e. instead of a mapping like:
> ProxyPassReverse /app/ http://internal-host:567/app
>
> which will map to : http://<ServerName>/app/
> it uses :
>
> ProxyPassReverse https://frontend-address/app/ http://internal-host:567/app
>
> which will map to the fixed URL supplied (the first part that is)

Your suggested patch makes ProxyPassReverse work more logically. Will
commit soon (unless there are objections).

Regards,
Graham
--
-----------------------------------------
minfrin [at] sharp.fm
"There's a moon
over Bourbon Street
tonight..."

> From: Graham Leggett [mailto:minfrin [at] sharp.fm]
>
> Martijn Schoemaker wrote:
>
> > i.e. instead of a mapping like:
> > ProxyPassReverse /app/ http://internal-host:567/app
> >
> > which will map to : http://<ServerName>/app/
> > it uses :
> >
> > ProxyPassReverse https://frontend-address/app/ http://internal-
> host:567/app
> >
> > which will map to the fixed URL supplied (the first part that is)
>
> Your suggested patch makes ProxyPassReverse work more logically. Will
> commit soon (unless there are objections).

I have no suggestion, but hasn't this already been done in 2.0? The
only problem with doing this in 1.3, is that we are unlikely to have
anymore 1.3 releases. We may be better off to just keep the patch on
the site.

Ryan

+1. Mod_proxy makes a very decent mapper this way. It is another good
reason to protect one's /conf jealously, so would a warning to this
effect in the docs be appropriate when this is put in?

Chuck

On Monday, July 29, 2002, at 09:47 AM, Foust, Adam G. wrote:

> This patch makes a lot of sense. This would be very useful to my
> organization. I hope it's seriously considered for incorporation in
> future mod_proxy releases.
>
> =A0
>
> We had implemented a configuration workaround:
>
> =A0
>
> ProxyPassReverse/cgi-
> =
bin/redir?http://externalhost:777/yadda/=A0http://internalho st:999/yadda/
>
> =A0
>
> ...that works, but using CGI is less than ideal. There's probably a
> slightly better way to do this with mod_rewrite, but patching
> ProxyPassReverse to be more versatile is hands-down the best solution.
>
> =A0
>
> -----Original Message-----
> From: Martijn Schoemaker [mailto:martijn [at] osp.nl]
> Sent:Monday, July 29, 20028:38 AM
> To: modproxy-dev [at] apache.org
> Subject: Patch to mod_proxy for fixed reverse mapping support
>
> =A0
>
> Hi,
>
> First of all, I would like to introduce myself. My name is
> Martijn Schoemaker and I so programming/systemadmin/everything
> *nix as my daytime job.
>
> I am currently working at a big customer with a pretty complex
> (too complex imho) proxy environment. This constists of
> netscape proxies, ssl accelerators, netcache appliances, layer-4
> switched and ofcourse apache proxies. In this environment we
> use https at the frontend which is 'converted' to http requests
> on the inside which are handled by the apache proxies. The problem
> is that mod_proxy (as in apache 1.3.26) cannot reverse map to
> urls outside it's own apache configuration. Because at different
> places after the proxy, redirects are sent which need to be
> rewritten to :=A0https://fontend-address.com/<things> but because
> mod_proxy uses the apache URL=A0construction routines is not
> possible (it will always map to http://<ServerName>/<rest>).
>
> For this to be possible I created a small patch which does a
> check on the 'fake' url if it contains a '://' and if so it
> will use that as the first part and only pastes the additional
> uri to that. If not, it just uses the apache url construction
> routine as its default.
>
> i.e. instead of a mapping like:
> ProxyPassReverse /app/=A0=A0=A0 http://internal-host:567/app
>
> which will map to :=A0http://<ServerName>/app/
> it uses :
>
> ProxyPassReverse https://frontend-address/app/ http://internal-
> host:567/app
>
> which will map to the fixed URL supplied (the first part that is)
>
> My question to you all is :=A0am I making sense ?=A0Can this be
> incorporated in future releases ?=A0As far as I can see this is
> only added value and no other fake url will contain '://' unless
> it is meant as fixed anyway.
>
> I'd greatly appreciate any comments :)
>
> Greetings,
> Martijn Schoemaker
> =A0
>
> --=A0
>
> ------ WARNING: This signature contains a VIRUS ! -------
>
> - SHLRUIOHUIOWHLNNMSKHKDLWINDOWSJHFHKJLLUIHEKJLNDHKKJHL -
>
> ---------------------------------------------------------
>
> =A0
>

Ryan Bloom wrote:

> I have no suggestion, but hasn't this already been done in 2.0? The
> only problem with doing this in 1.3, is that we are unlikely to have
> anymore 1.3 releases. We may be better off to just keep the patch on
> the site.

AFAIK v2.0 doesn't (does it?) - I was going to commit to v2.0, and then
to v1.3 for completeness (even if there are no new versions of v1.3, at
least it's there).

Regards,
Graham
--
-----------------------------------------
minfrin [at] sharp.fm
"There's a moon
over Bourbon Street
tonight..."

Okay, you are right, I read the purpose of the patch incorrectly the
first time.

Ryan

----------------------------------------------
Ryan Bloom
rbb [at] covalent.net rbb [at] apache.org

> -----Original Message-----
> From: Graham Leggett [mailto:minfrin [at] sharp.fm]
> Sent: Monday, July 29, 2002 12:14 PM
> To: modproxy-dev [at] apache.org
> Subject: Re: Patch to mod_proxy for fixed reverse mapping support
>
> Ryan Bloom wrote:
>
> > I have no suggestion, but hasn't this already been done in 2.0? The
> > only problem with doing this in 1.3, is that we are unlikely to have
> > anymore 1.3 releases. We may be better off to just keep the patch
on
> > the site.
>
> AFAIK v2.0 doesn't (does it?) - I was going to commit to v2.0, and
then
> to v1.3 for completeness (even if there are no new versions of v1.3,
at
> least it's there).
>
> Regards,
> Graham
> --
> -----------------------------------------
> minfrin [at] sharp.fm
> "There's a moon
> over Bourbon Street
> tonight..."

On Mon, 2002-07-29 at 12:14, Graham Leggett wrote:
> Ryan Bloom wrote:
>
> > I have no suggestion, but hasn't this already been done in 2.0? The
> > only problem with doing this in 1.3, is that we are unlikely to have
> > anymore 1.3 releases. We may be better off to just keep the patch on
> > the site.
>
> AFAIK v2.0 doesn't (does it?) - I was going to commit to v2.0, and then
> to v1.3 for completeness (even if there are no new versions of v1.3, at
> least it's there).
>

before you commit the change to 2.0 can you make sure that the existing
behavior is still maintained/available, and if it can't be then you will
need to make a new directive.

also.. what about virtual hosts.. doesn't requiring them to have a
hostname break them?

> Regards,
> Graham
> --
> -----------------------------------------
> minfrin [at] sharp.fm
> "There's a moon
> over Bourbon Street
> tonight..."
--
Ian Holsman
Performance Measurement & Analysis
CNET Networks
PH: 415-344-2608

Ian Holsman wrote:

> before you commit the change to 2.0 can you make sure that the existing
> behavior is still maintained/available, and if it can't be then you will
> need to make a new directive.

There is no change that I can see to existing behaviour (there was no
previous sane behaviour for ProxyPassReverse http://blah/ http://foo/)

> also.. what about virtual hosts.. doesn't requiring them to have a
> hostname break them?

There is no requirement to have a hostname - the old behaviour still holds.

Regards,
Graham
--
-----------------------------------------
minfrin [at] sharp.fm
"There's a moon
over Bourbon Street
tonight..."

>> also.. what about virtual hosts.. doesn't requiring them to have a
>> hostname break them?

Doe the new config allow to target URLs outside of the scope of a virtual
host directive if
used within a virual host section ?

>
> There is no requirement to have a hostname - the old behaviour still
> holds.
>

--------------4AA40A991627728A5B0F5A2A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

The new config will use the target specified in the
config file 'as-is' and thus has no further link to
any virtual host or internal configuration what so-
ever.

Greets,
Martijn

Manon Goo wrote:

> >> also.. what about virtual hosts.. doesn't requiring them to have a
> >> hostname break them?
>
> Doe the new config allow to target URLs outside of the scope of a virtual
> host directive if
> used within a virual host section ?
>
> >
> > There is no requirement to have a hostname - the old behaviour still
> > holds.
> >

--
------ WARNING: This signature contains a VIRUS ! -------
- SHLRUIOHUIOWHLNNMSKHKDLWINDOWSJHFHKJLLUIHEKJLNDHKKJHL -
---------------------------------------------------------

--------------4AA40A991627728A5B0F5A2A
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi,
The new config will use the target specified in the
 config file 'as-is' and thus has no further link to
 any virtual host or internal configuration what so-
 ever.
Greets,
 Martijn
Manon Goo wrote:
<blockquote TYPE=CITE>>> also.. what about virtual hosts.. doesn't requiring
them to have a
 >> hostname break them?
Doe the new config allow to target URLs outside of the scope of a virtual
 host directive if
 used within a virual host section ?
>
 > There is no requirement to have a hostname - the old behaviour still
 > holds.
 ></blockquote>

<pre>--
------ WARNING: This signature contains a VIRUS ! -------
- SHLRUIOHUIOWHLNNMSKHKDLWINDOWSJHFHKJLLUIHEKJLNDHKKJHL -
---------------------------------------------------------</pre>
</html>

--------------4AA40A991627728A5B0F5A2A--

I do not think it is a good idea to be able to configure someting inside a
virtual host that tragets URLs outside it. This is fine in the
"server config" or in a _default_ virtual host but nowhere else. especialy
in enviroments whith many virtual hosts, vhost in diffrent includefiles
edited by different persons.

Manon

--On Dienstag, 30. Juli 2002 13:16 Uhr +0200 Martijn Schoemaker
<martijn [at] osp.nl> wrote:

> Hi,
>
> The new config will use the target specified in the
> config file 'as-is' and thus has no further link to
> any virtual host or internal configuration what so-
> ever.
>
> Greets,
> Martijn
>
> Manon Goo wrote:
>
>>> also.. what about virtual hosts.. doesn't requiring them to have a
>>> hostname break them?
>
> Doe the new config allow to target URLs outside of the scope of a virtual
> host directive if
> used within a virual host section ?
>
>>
>> There is no requirement to have a hostname - the old behaviour still
>> holds.
>>
>
>
> --
> ------ WARNING: This signature contains a VIRUS ! -------
> - SHLRUIOHUIOWHLNNMSKHKDLWINDOWSJHFHKJLLUIHEKJLNDHKKJHL -
> ---------------------------------------------------------
>

Nobody is forcing virtual host users to use the new functionality,
they can still do path based ProxyPassReverse statements that will
assume the virtual host's domain name. However, I think it would be
unfortunate to disable this additional functionality to everybody in
order to prevent virtual host users from misusing the new
functionality.

-bmd

On Tue, Jul 30, 2002 at 01:59:22PM +0200, Manon Goo wrote:
> I do not think it is a good idea to be able to configure someting inside a
> virtual host that tragets URLs outside it. This is fine in the
> "server config" or in a _default_ virtual host but nowhere else. especialy
> in enviroments whith many virtual hosts, vhost in diffrent includefiles
> edited by different persons.
>
> Manon
>
>
> --On Dienstag, 30. Juli 2002 13:16 Uhr +0200 Martijn Schoemaker
> <martijn [at] osp.nl> wrote:
>
> > Hi,
> >
> > The new config will use the target specified in the
> > config file 'as-is' and thus has no further link to
> > any virtual host or internal configuration what so-
> > ever.
> >
> > Greets,
> > Martijn
> >
> > Manon Goo wrote:
> >
> >>> also.. what about virtual hosts.. doesn't requiring them to have a
> >>> hostname break them?
> >
> > Doe the new config allow to target URLs outside of the scope of a virtual
> > host directive if
> > used within a virual host section ?
> >
> >>
> >> There is no requirement to have a hostname - the old behaviour still
> >> holds.
> >>
> >
> >
> > --
> > ------ WARNING: This signature contains a VIRUS ! -------
> > - SHLRUIOHUIOWHLNNMSKHKDLWINDOWSJHFHKJLLUIHEKJLNDHKKJHL -
> > ---------------------------------------------------------
> >
>
>

--==========2147489406==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

--On Dienstag, 30. Juli 2002 9:28 Uhr -0700 Brian Degenhardt <bmd [at] mp3.com>
wrote:

> Nobody is forcing virtual host users to use the new functionality,
> they can still do path based ProxyPassReverse statements that will
> assume the virtual host's domain name. However, I think it would be
> unfortunate to disable this additional functionality to everybody in
> order to prevent virtual host users from misusing the new
> functionality.

True too ....
>
> -bmd
>
> On Tue, Jul 30, 2002 at 01:59:22PM +0200, Manon Goo wrote:
>> I do not think it is a good idea to be able to configure someting inside
>> a virtual host that tragets URLs outside it. This is fine in the
>> "server config" or in a _default_ virtual host but nowhere else.
>> especialy in enviroments whith many virtual hosts, vhost in diffrent
>> includefiles edited by different persons.
>>
>> Manon
>>
>>
>> --On Dienstag, 30. Juli 2002 13:16 Uhr +0200 Martijn Schoemaker
>> <martijn [at] osp.nl> wrote:
>>
>> > Hi,
>> >
>> > The new config will use the target specified in the
>> > config file 'as-is' and thus has no further link to
>> > any virtual host or internal configuration what so-
>> > ever.
>> >
>> > Greets,
>> > Martijn
>> >
>> > Manon Goo wrote:
>> >
>> >>> also.. what about virtual hosts.. doesn't requiring them to have a
>> >>> hostname break them?
>> >
>> > Doe the new config allow to target URLs outside of the scope of a
>> > virtual host directive if
>> > used within a virual host section ?
>> >
>> >>
>> >> There is no requirement to have a hostname - the old behaviour still
>> >> holds.
>> >>
>> >
>> >
>> > --
>> > ------ WARNING: This signature contains a VIRUS ! -------
>> > - SHLRUIOHUIOWHLNNMSKHKDLWINDOWSJHFHKJLLUIHEKJLNDHKKJHL -
>> > ---------------------------------------------------------
>> >
>>
>>

--==========2147489406==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (Darwin)

iD8DBQE9RsYs4N5kPCP8wnsRAq3HAJkBcTbSc8YZ3CgNf7gVAnD4hOZC3gCf dh4t
r9xwJscJFDoZdbb0ZPdxQ0k=
=Ey98
-----END PGP SIGNATURE-----

--==========2147489406==========--

Patch to mod_proxy for fixed reverse mapping support

RE: Patch to mod_proxy for fixed reverse mapping support

Re: Patch to mod_proxy for fixed reverse mapping support

RE: Patch to mod_proxy for fixed reverse mapping support

Re: Patch to mod_proxy for fixed reverse mapping support

Re: Patch to mod_proxy for fixed reverse mapping support

RE: Patch to mod_proxy for fixed reverse mapping support

Re: Patch to mod_proxy for fixed reverse mapping support

Re: Patch to mod_proxy for fixed reverse mapping support

Re: Patch to mod_proxy for fixed reverse mapping support

Re: Patch to mod_proxy for fixed reverse mapping support

Re: Patch to mod_proxy for fixed reverse mapping support

Re: Patch to mod_proxy for fixed reverse mapping support

Re: Patch to mod_proxy for fixed reverse mapping support