hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ortwin Gl├╝ck <...@odi.ch>
Subject Re: [HttpClient] Adjusting location URIs
Date Thu, 25 Oct 2007 13:34:01 GMT

ossfwot@dubioso.net wrote:
> 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 would also mean to rewrite URLs in the message body - and that's
not something you really want. But yes, I agree, that would be "correct".

> See, there is a problem. Relative HTML links are
> resolved relative to the <BASE> 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.

Okay, it makes sense to use Content-Location in that light.

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

or Multipart MIME responses ;-)

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

Prepare for a user who wants to supply his custom base URI...
Maybe we should put that code in a protected method, so it can easily be
replaced in a subclass?

> cheers,
>   Roland


[web]  http://www.odi.ch/
[blog] http://www.odi.ch/weblog/
[pgp]  key 0x81CF3416
       finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416

To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org

View raw message