hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ossf...@dubioso.net
Subject Re: [HttpClient] Adjusting location URIs
Date Thu, 25 Oct 2007 13:16:36 GMT
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 <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.

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


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

View raw message