Return-Path: Delivered-To: apmail-httpd-users-archive@www.apache.org Received: (qmail 25952 invoked from network); 5 Feb 2009 09:18:25 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 5 Feb 2009 09:18:25 -0000 Received: (qmail 52269 invoked by uid 500); 5 Feb 2009 09:18:14 -0000 Delivered-To: apmail-httpd-users-archive@httpd.apache.org Received: (qmail 52251 invoked by uid 500); 5 Feb 2009 09:18:14 -0000 Mailing-List: contact users-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: users@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@httpd.apache.org Received: (qmail 52242 invoked by uid 99); 5 Feb 2009 09:18:14 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 05 Feb 2009 01:18:14 -0800 X-ASF-Spam-Status: No, hits=1.5 required=10.0 tests=SPF_PASS,WEIRD_PORT X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of aw@ice-sa.com designates 212.85.38.174 as permitted sender) Received: from [212.85.38.174] (HELO popeye.combios.es) (212.85.38.174) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 05 Feb 2009 09:18:05 +0000 Received: from [192.168.250.51] (p549EA734.dip0.t-ipconnect.de [84.158.167.52]) (authenticated bits=0) by popeye.combios.es (8.13.8/8.13.8/Debian-3) with ESMTP id n159HZKl031148 for ; Thu, 5 Feb 2009 10:17:40 +0100 Message-ID: <498AADA9.9030403@ice-sa.com> Date: Thu, 05 Feb 2009 10:13:13 +0100 From: =?ISO-8859-1?Q?Andr=E9_Warnier?= User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: users@httpd.apache.org References: <498AA029.6060401@csulb.edu> In-Reply-To: <498AA029.6060401@csulb.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92.1/8951/Thu Feb 5 06:07:22 2009 on popeye.combios.es X-Virus-Status: Clean X-Virus-Checked: Checked by ClamAV on apache.org Subject: Re: [users@httpd] port issue with reverse proxy Mike Soultanian wrote: > Per my initial requirements, I was able to get reverse proxy working > pretty well so my legacy web app sees every request originating from > itself. To do this, I'm using the following: > > proxyrequests off > > NameVirtualHost *:80 > NameVirtualHost myserver.tld:81 > > > ProxyPass / http://myserver.tld:81/ > ProxyPassReverse / http://myserver.tld:81/ > > > > DocumentRoot c:\inetpub\wwwroot > > > The only problem now is that new links within the app are getting > created with :81 appended to the URL. Unfortunately I can't change how > the app works so I wanted to see if there is some way to report the port > as 80 so subsequently selected links will be forced back through the > first virtualhost like the initial request. Sound possible? > Hi. (I'm no expert, just following this to try and understand it myself) Looking at : http://httpd.apache.org/docs/2.2/mod/mod_proxy.html#proxypassreverse it seems to concern only HTTP re-direct headers, not links within the html pages themselves. Does your app really generate absolute links within the html response pages themselves ? I mean, if in your browser you get such a response page, and look at the html source of the page, do you really see links to "http://myserver.tld:81/...", or are they more like "/something/something_else", or even relative like "images/img1.gif" ? If they are really absolute to "http://..", then you might need the mod_proxy_html module, as also indicated in the above doc. section. But otherwise, maybe you are just being confused between what the browser does to interpret relative links and what the server actually does ? --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See for more info. To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org " from the digest: users-digest-unsubscribe@httpd.apache.org For additional commands, e-mail: users-help@httpd.apache.org