Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 78100 invoked from network); 19 Sep 2005 09:36:34 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 19 Sep 2005 09:36:34 -0000 Received: (qmail 61017 invoked by uid 500); 19 Sep 2005 09:36:31 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 60989 invoked by uid 500); 19 Sep 2005 09:36:31 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@cocoon.apache.org List-Id: Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 60973 invoked by uid 99); 19 Sep 2005 09:36:31 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 19 Sep 2005 02:36:31 -0700 X-ASF-Spam-Status: No, hits=0.1 required=10.0 tests=FORGED_RCVD_HELO X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: local policy) Received: from [66.111.4.28] (HELO out4.smtp.messagingengine.com) (66.111.4.28) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 19 Sep 2005 02:36:39 -0700 Received: from frontend1.internal (mysql-sessions.internal [10.202.2.149]) by frontend1.messagingengine.com (Postfix) with ESMTP id 61075CCF368 for ; Mon, 19 Sep 2005 05:36:27 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.151]) by frontend1.internal (MEProxy); Mon, 19 Sep 2005 05:36:27 -0400 X-Sasl-enc: L8bZzP8N/RJAeN+NsWs0sLPi51A3cZJ3T68OJrsccsnP 1127122586 Received: from [10.0.0.3] (elfriedeholmes.demon.co.uk [80.177.165.206]) by www.fastmail.fm (Postfix) with ESMTP id 91E1C5703B5 for ; Mon, 19 Sep 2005 05:36:26 -0400 (EDT) Message-ID: <432E8694.4040601@odoko.co.uk> Date: Mon, 19 Sep 2005 10:36:20 +0100 From: Upayavira Organization: Odoko Ltd User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050912) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: Regression on DefaultLinkService References: <20050916134435.GA7961@vision.anyware> <432E6A38.3000807@apache.org> <20050919082014.GA21944@vision.anyware> <432E7BD6.5030000@apache.org> <20050919090321.GC21944@vision.anyware> <432E8492.6030002@apache.org> In-Reply-To: <432E8492.6030002@apache.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Carsten Ziegeler wrote: > Jean-Baptiste Quenot wrote: > >>Indeed, Upa was right in suggesting that we use Apache as >>a proxy with ProxyPass directive. The server name used to >>access the application is not the same as the one returned by >>request.getServerName(). >> > > I'm not sure, but I think ProxyPass sets the server as an additional > request header, "Via" or something like that. If this is true, we could > also check this header in the link service. WDYT? You set ProxyVia on in your httpd.conf and it will set a Via header. Interesting. This should be used in a lot more places besides, e.g. the HostSelector - it could have made my life _much_ easier. > >>>Can you solve your problem this way? What configuration do you >>>have? Give us some more information and I'm sure we can fix the >>>problem. >> >> >>Generally speaking in our application we need somewhere a >>configuration file where we store the server name. Maybe the >>server name can be passed in the portal components configuration? > > Yeah, this would be possible, of course. But I think this should be the > final solution. What happens, if you use the same portal instances for > two virtual hosts? Then you need to use something like Via, or proxy to the correct hostname, or pass a key in with the request that specifies what domain it is associated with. Regards, Upayavira