Return-Path: Delivered-To: apmail-jakarta-httpcomponents-dev-archive@www.apache.org Received: (qmail 47630 invoked from network); 25 Oct 2007 13:17:06 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 25 Oct 2007 13:17:06 -0000 Received: (qmail 6521 invoked by uid 500); 25 Oct 2007 13:16:53 -0000 Delivered-To: apmail-jakarta-httpcomponents-dev-archive@jakarta.apache.org Received: (qmail 6484 invoked by uid 500); 25 Oct 2007 13:16:53 -0000 Mailing-List: contact httpcomponents-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "HttpComponents Project" Delivered-To: mailing list httpcomponents-dev@jakarta.apache.org Received: (qmail 6475 invoked by uid 99); 25 Oct 2007 13:16:53 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 25 Oct 2007 06:16:53 -0700 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_HELO_PASS,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [212.227.126.183] (HELO moutng.kundenserver.de) (212.227.126.183) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 25 Oct 2007 13:16:57 +0000 Received: from pustefix161.kundenserver.de (pustefix161.kundenserver.de [172.23.4.28]) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis) id 0ML25U-1Il2Zg0fED-0005Jo; Thu, 25 Oct 2007 15:16:36 +0200 Message-Id: <11352840.631591193318196043.JavaMail.servlet@kundenserver> From: ossfwot@dubioso.net To: Subject: Re: [HttpClient] Adjusting location URIs MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 X-Binford: 6100 (more power) X-Mailer: Webmail X-Originating-From: 27019222 X-Routing: DE X-Message-Id: <27019222$1193318195955172.23.4.2816758979@pustefix161.kundenserver.de--1132814199> X-Received: from pustefix161.kundenserver.de by 149.229.96.209 with HTTP id 27019222 for [httpcomponents-dev@jakarta.apache.org]; Thu, 25 Oct 2007 15:16:35 CEST Date: Thu, 25 Oct 2007 15:16:36 +0200 X-Provags-ID: V01U2FsdGVkX19lOtT7ra/gq+hcihN84prITIIWMmkNMKjixfO G6HXGCe9pFyGTfcMFI6pfWmAc9F1Av5LolNzmruAP2rkIWp8jO 426ScvWzKz9IS+GSu0z/g== X-Virus-Checked: Checked by ClamAV on apache.org Hello Odi, > Consider mod_jk configured to map > - /1/context -> /context on host1 > - /2/context -> /context on host2 > > The webapp can not know of the /1 and /2 prefix that the client used in > its original request. So mod_jk would have to rewrite the location > header (apparently doesn't). Yes, it should process responses in the reverse way of processing the request. > That's why every real-world implementation treats relative location > header redirects the same way as relative HTML links. It's the only > interpretation that makes sense. See, there is a problem. Relative HTML links are resolved relative to the tag in the HTML, if present. Then there's the Content-Location that can give the base on the HTTP level. And finally, the request URI is the last fallback. >> Or the Content-Location header, if present? > > That interpretation seems quite arbitrary to me. > Any real-world examples where this header is used? I'd expect that real-world browsers would screw up badly if anyone actually used Content-Location. I noticed it a few years ago, it's probably as widely used as transfer compression ;-) At least for websites. > We are speaking about the option when we explicitly allow relative > redirects. So treat them in the most meaningful way. I always considered that to mean server-relative but path-absolute. Anyway, go ahead with using the request URI as the base. It's not like we've got a spec we could violate with that :-) cheers, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org