Re: NEW ISSUE: Drop Content-Location

On Wed, 29 Nov 2006 22:40:25 +0100, Julian Reschke <>  

> Anne van Kesteren schrieb:
>>  It basically can't be implemented by web browsers. See for instance  
>> ... We've tried it  
>> as well, broke the web, and then backed it out again.
>>  Perhaps Content-Base or so can be resurrected...
> Hm.
>  From what I see the problem was that many deployed servers return a  
> Content-Location header containing a URI which in fact isn't accessible  
> from the outside. That's a server bug.

There were quite a few variations, including at least one identifying a  
different port. We ended up restricting the header to same protocol, same  
server, same port. And that was not enough.

> The header allows relative URIs, so it seems to me it would be safe for  
> user agents to support the header if - for instance - it's an absolute  
> path. That should still cover the majority of the use cases...

Sorry, Julien. Won't work.

Absolute URI: : Content-Location is . Two years ago important parts of  
this site did not work due to the wrong Content-Location being used as  
Base URL. The website is currently using absolute paths for everything.  
Wonder why? Content-Location is . The webpage contain a  
relative reference to images/headerbutton.jpg . If resolved to you get a 404.

Absolute path: :  
Content-Location is /category.jsp . This page uses relative URLs in the  
links and images. The result of using Content-Location as Base-URI here is  
that the page will not work

Serverbug or configuration issue, there were (and are) enough of these  
examples that we had to disable the functionality.

Short story: Given the incorrect usage we have seen in the past few years  
it is not possible to implement client side support of Content-Location as  
a Base URL replacement. If such functionality is desired, an entirely new  
header must be defined.

Yngve N. Pettersen
Senior Developer                     Email:
Opera Software ASA         
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01

Received on Wednesday, 29 November 2006 22:54:30 UTC