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 :-) cheers, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
