Patch to mod_proxy for fixed reverse mapping support

Patch to mod_proxy for fixed reverse mapping support

am 29.07.2002 14:37:57 von Martijn Schoemaker

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/ but because
mod_proxy uses the apache URL construction routines is not
possible (it will always map to http:///).

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:///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



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 : <things> but because

mod_proxy uses the apache URL construction routines is not

possible (it will always map to <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/   

which will map to : <ServerName>/app/

it uses :

ProxyPassReverse

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--

--------------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--

RE: Patch to mod_proxy for fixed reverse mapping support

am 29.07.2002 18:47:22 von agfoust

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@osp.nl]
Sent: Monday, July 29, 2002 8:38 AM
To: modproxy-dev@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/
but because
mod_proxy uses the apache URL construction routines is not
possible (it will always map to http:// /).
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:// /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 -
---------------------------------------------------------


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


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">


charset=3Dus-ascii">






namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
name=3D"time"/>
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
name=3D"date"/>





style=3D'tab-interval:.5in'>



style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>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.



style=3D'font-size:
10.0pt;font-family:Arial;color:navy'> 

=


style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>We had implemented a configuration
workaround:



style=3D'font-size:
10.0pt;font-family:Arial;color:navy'> 

=


class=3DSpellE> color=3Dnavy face=3DArial> style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>ProxyPassReverse
color=3Dnavy
face=3DArial> style=3D'font-size:10.0pt;font-family:Arial;color:navy'> =
/cgi-bin/redir class=3DGramE>?http
://externalhost:777/yadda/ style=3D'mso-spacerun:yes'>  =
http://internalhost:999/yadda/



style=3D'font-size:
10.0pt;font-family:Arial;color:navy'> 

=


style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>...that works, but using CGI is =
less
than ideal. There's probably a slightly better way to do this with =
class=3DSpellE>mod_rewrite
, but patching class=3DSpellE>ProxyPassReverse
to be more versatile is hands-down the best =
solution.



style=3D'font-size:
10.0pt;font-family:Arial;color:navy'> 

=


face=3DTahoma> style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----

From: Martijn Schoemaker
[mailto:martijn@osp.nl]

Sent
style=3D'font-weight:bold'>:
Month=3D"7" Day=3D"29"
Year=3D"2002"> style=3D'font-size:10.0pt;font-family:
Tahoma'>Monday, July 29, 2002
face=3DTahoma> =
Hour=3D"8" Minute=3D"38"> style=3D'font-size:10.0pt;
font-family:Tahoma'>8:38 AM
face=3DTahoma> style=3D'font-size:10.0pt;font-family:Tahoma'>

To: =
modproxy-dev@apache.org

Subject: Patch to =
mod_proxy for
fixed reverse mapping support



face=3D"Times New Roman"> style=3D'font-size:12.0pt'> 



face=3D"Times New Roman"> style=3D'font-size:12.0pt'>Hi,



Roman"> style=3D'font-size:12.0pt'>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.



Roman"> style=3D'font-size:12.0pt'>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 :  href=3D"https://fontend-address.com/">https://fontend-addres s.com/&l=
t;things>
but because

mod_proxy uses the apache URL construction routines is not

possible (it will always map to href=3D"http://">http://<ServerName>/<rest>).



Roman"> style=3D'font-size:12.0pt'>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.



Roman"> style=3D'font-size:12.0pt'>i.e. instead of a mapping like:

ProxyPassReverse /app/    href=3D"http://internal-host:567/app">http://internal-host:5 67/app



Roman"> style=3D'font-size:12.0pt'>which will map to :  href=3D"http://">http://<ServerName>/app/


it uses :



Roman"> style=3D'font-size:12.0pt'>ProxyPassReverse href=3D"https://frontend-address/app/">https://frontend-addr ess/app/=
href=3D"http://internal-host:567/app">http://internal-host:5 67/app =



Roman"> style=3D'font-size:12.0pt'>which will map to the fixed URL supplied =
(the first
part that is)



Roman"> style=3D'font-size:12.0pt'>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.



Roman"> style=3D'font-size:12.0pt'>I'd greatly appreciate any comments :) =



Roman"> style=3D'font-size:12.0pt'>Greetings,

Martijn Schoemaker

 




New">
style=3D'font-size:10.0pt'>-- 
style=3D'margin-left:.5in'> style=3D'font-size:10.0pt'>------ WARNING: This signature contains a =
VIRUS ! -------
style=3D'margin-left:.5in'> style=3D'font-size:10.0pt'>- =
SHLRUIOHUIOWHLNNMSKHKDLWINDOWSJHFHKJLLUIHEKJLNDHKKJHL =
-
style=3D'margin-left:.5in'> style=3D'font-size:10.0pt'>--------------------------------- ------------=
------------


face=3D"Times New Roman"> style=3D'font-size:12.0pt'> 









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

Re: Patch to mod_proxy for fixed reverse mapping support

am 29.07.2002 21:01:03 von Graham Leggett

Martijn Schoemaker wrote:

> i.e. instead of a mapping like:
> ProxyPassReverse /app/ http://internal-host:567/app
>
> which will map to : http:///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@sharp.fm
"There's a moon
over Bourbon Street
tonight..."

RE: Patch to mod_proxy for fixed reverse mapping support

am 29.07.2002 21:07:25 von Ryan Bloom

> From: Graham Leggett [mailto:minfrin@sharp.fm]
>
> Martijn Schoemaker wrote:
>
> > i.e. instead of a mapping like:
> > ProxyPassReverse /app/ http://internal-host:567/app
> >
> > which will map to : http:///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

Re: Patch to mod_proxy for fixed reverse mapping support

am 29.07.2002 21:10:35 von Chuck Murcko

+1. Mod_proxy makes a very decent mapper this way. It is another good=20
reason to protect one's /conf jealously, so would a warning to this=20
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=20
> organization. I hope it's seriously considered for incorporation in=20
> 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=20
> slightly better way to do this with mod_rewrite, but patching=20
> ProxyPassReverse to be more versatile is hands-down the best solution.
>
> =A0
>
> -----Original Message-----
> From: Martijn Schoemaker [mailto:martijn@osp.nl]
> Sent:Monday, July 29, 20028:38 AM
> To: modproxy-dev@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/ but because
> mod_proxy uses the apache URL=A0construction routines is not
> possible (it will always map to http:///).
>
> 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 http://internal-host:567/app
>
> which will map to :=A0http:///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
>

Re: Patch to mod_proxy for fixed reverse mapping support

am 29.07.2002 21:14:00 von Graham Leggett

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@sharp.fm
"There's a moon
over Bourbon Street
tonight..."

RE: Patch to mod_proxy for fixed reverse mapping support

am 29.07.2002 21:28:46 von Ryan Bloom

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

Ryan

----------------------------------------------
Ryan Bloom
rbb@covalent.net rbb@apache.org

> -----Original Message-----
> From: Graham Leggett [mailto:minfrin@sharp.fm]
> Sent: Monday, July 29, 2002 12:14 PM
> To: modproxy-dev@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@sharp.fm
> "There's a moon
> over Bourbon Street
> tonight..."

Re: Patch to mod_proxy for fixed reverse mapping support

am 29.07.2002 22:12:43 von Ian Holsman

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@sharp.fm
> "There's a moon
> over Bourbon Street
> tonight..."
--
Ian Holsman
Performance Measurement & Analysis
CNET Networks
PH: 415-344-2608

Re: Patch to mod_proxy for fixed reverse mapping support

am 29.07.2002 22:25:05 von Graham Leggett

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@sharp.fm
"There's a moon
over Bourbon Street
tonight..."

Re: Patch to mod_proxy for fixed reverse mapping support

am 30.07.2002 12:48:32 von Manon Goo

>> 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.
>

Re: Patch to mod_proxy for fixed reverse mapping support

am 30.07.2002 13:16:10 von Martijn Schoemaker

--------------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



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--

Re: Patch to mod_proxy for fixed reverse mapping support

am 30.07.2002 13:59:22 von Manon Goo

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
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 -
> ---------------------------------------------------------
>

Re: Patch to mod_proxy for fixed reverse mapping support

am 30.07.2002 18:28:21 von Brian Degenhardt

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
> 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 -
> > ---------------------------------------------------------
> >
>
>

Re: Patch to mod_proxy for fixed reverse mapping support

am 30.07.2002 19:00:28 von Manon Goo

--==========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 =20
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
>> 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==========--