[EMAIL PROTECTED] wrote: > Hello Odi, > >> No, we must not prepend a / as this would change the semantics. > > What is the semantics of something that is not specified? > RFC 2616 requires absolute URIs. (section 14.30)
Roland, I know that it's not specified. And this is IMHO a horrible design flaw in the RFC. Because it assumes that a webserver is actually able to reconstruct an absolute URI for a specific client. But that's simply impossible in all but the most simple server setups. A webapplication usually isn't even able to know its absolute path. It's actually best practice to ONLY use relative redirects! Otherwise the application is simply incompatible with a custom URL mapping in reverse proxies (applies to many webapp frameworks!). 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). 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. >> Instead the resulting URI must be resolved against the request URI: > > Or the Content-Location header, if present? That interpretation seems quite arbitrary to me. Any real-world examples where this header is used? > I suggest to trigger an exception for relative paths. We are speaking about the option when we explicitly allow relative redirects. So treat them in the most meaningful way. > cheers, > Roland Cheers Ortwin -- [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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
