NEW ISSUE: Drop Content-Location

[Anne van Kesteren-2]

It basically can't be implemented by web browsers. See for instance  
https://bugzilla.mozilla.org/show_bug.cgi?id=109553 ... We've tried it as  
well, broke the web, and then backed it out again.

Perhaps Content-Base or so can be resurrected...


--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

[Julian Reschke]

Anne van Kesteren schrieb:
>
> It basically can't be implemented by web browsers. See for instance
> https://bugzilla.mozilla.org/show_bug.cgi?id=109553 ... 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.

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

Best regards, Julian

[Roy T. Fielding]

On Nov 29, 2006, at 12:24 PM, Anne van Kesteren wrote:
> It basically can't be implemented by web browsers. See for instance  
> https://bugzilla.mozilla.org/show_bug.cgi?id=109553 ... We've tried  
> it as well, broke the web, and then backed it out again.

No. It is pathetic that some vendors choose to drop features rather
than deploy version-specific workarounds, but not entirely unexpected.
The only thing that should be changed at this point is 14.14:

    The value of Content-Location also defines the base URI for the
    entity.

s/also defines/does not define/;

Such a change would not effect current practice and would still allow
Content-Location to be useful for all of the other reasons it exists
(none of which are broken by IIS or MSIE because they don't author).

> Perhaps Content-Base or so can be resurrected...

That is impossible without changing the HTTP version number.

....Roy

[Anne van Kesteren-2]

On Wed, 29 Nov 2006 22:40:25 +0100, Julian Reschke <julian.reschke@...>  
wrote:
> 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.

I'm sure you read https://bugzilla.mozilla.org/show_bug.cgi?id=109553#c37 
as well which suggests otherwise. Also, whether it's servers or clients  
that are broken doesn't really matter. The simple fact is that the header  
can't be supported.


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

 From my recollection we can't really implement it in any way.


--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

[Henrik Nordstrom-2]

ons 2006-11-29 klockan 21:24 +0100 skrev Anne van Kesteren:
> It basically can't be implemented by web browsers. See for instance  
> https://bugzilla.mozilla.org/show_bug.cgi?id=109553 ... We've tried it as  
> well, broke the web, and then backed it out again.

Well.. partly because you want to support client side http-equiv parsing
at the same time I would suspect.. which isn't what http-equiv is meant
to be used for. These headers is meant to be processed on the server.
Allowing http-equiv to be parsed in the client is a mistake as it
creates a mismatch between the HTTP protocol and how the client behaves
creating an ever widening gap allowing HTTP misconfiguration to go
largely unnoticed. See the HTML specifications if in doubt.

It's not valid to have more than one Content-Location. Any response
having multiple Content-Location is on it's own wrt what the value of
Content-Location is understood to be.. It may be the first, last,
sequentially resolved (when relative URLs is used), or even the two
concatenated with a comma if something along the way chooses to merge
the headers..

Content-Location plays a fairly important role in caching invalidation
and also processing of Vary responses, and dropping it would
theoretically cripple the caching support in the HTTP protocol quite
noticeably even if very few caches currently implements it correctly..

Regards
Henrik

[Anne van Kesteren-2]

On Wed, 29 Nov 2006 22:50:01 +0100, Henrik Nordstrom <hno@...>  
wrote:
> ons 2006-11-29 klockan 21:24 +0100 skrev Anne van Kesteren:
>> It basically can't be implemented by web browsers. See for instance
>> https://bugzilla.mozilla.org/show_bug.cgi?id=109553 ... We've tried it  
>> as
>> well, broke the web, and then backed it out again.
>
> Well.. partly because you want to support client side http-equiv parsing
> at the same time I would suspect.. which isn't what http-equiv is meant
> to be used for. These headers is meant to be processed on the server.

I've no idea why you're bringing this up. This has nothing to do with the  
issue I raised.


--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

[Anne van Kesteren-2]

On Wed, 29 Nov 2006 22:41:11 +0100, Roy T. Fielding <fielding@...>  
wrote:
>> It basically can't be implemented by web browsers. See for instance  
>> https://bugzilla.mozilla.org/show_bug.cgi?id=109553 ... We've tried it  
>> as well, broke the web, and then backed it out again.
>
> No. It is pathetic that some vendors choose to drop features rather
> than deploy version-specific workarounds, but not entirely unexpected.

Vendors have tried and have tried to deploy workarounds. By  
blacklisting/whitelisting servers etc. Didn't work out.


>> Perhaps Content-Base or so can be resurrected...
>
> That is impossible without changing the HTTP version number.

It's not like HTTP is validated or anything. The whole HTTP specification  
seems quite open to incremental additions and changes.


Anyway, I'm saying we can't implement it. You say we can do trickery. I'm  
not that concerned with what the (eventual) HTTP specification says on the  
matter, but it would be nice if it reflected reality (e.g.,  
implementations). If that's impossible, fine. I suppose we have to deal  
with the way we have dealt with HTML over the past eight years or so...  
(Trying to get interoperability based on real world usage and deployment  
without any standards body to help with that.)


--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

[Henrik Nordstrom-2]

ons 2006-11-29 klockan 13:41 -0800 skrev Roy T. Fielding:

>     The value of Content-Location also defines the base URI for the
>     entity.
>
> s/also defines/does not define/;
>
> Such a change would not effect current practice and would still allow
> Content-Location to be useful for all of the other reasons it exists
> (none of which are broken by IIS or MSIE because they don't author).

Partly agreed as it's unlikely the header will ever get supported by
clients in the current state of things, but please note it's also in
RFC2396->RFC2110.

There is no doubt that servers sending bad Content-Location is broken,
and this in large due to clients not supporting it so server admins
hasn't noticed they are sending bad Content-Location headers.

It's worth noting that in many cases servers sending bad
Content-Location headers is also sending bad Location headers, often
seen if you drop the last / on a directory request etc...

Regards
Henrik

[Henrik Nordstrom-2]

ons 2006-11-29 klockan 22:52 +0100 skrev Anne van Kesteren:

> I've no idea why you're bringing this up. This has nothing to do with the  
> issue I raised.

Sorry, I didn't notice your email before responding. Got a bit irritated
reading the Mozilla bug report you referenced bragging about also
snarfing the header from meta http-equiv when specs clearly says they
MUST NOT. I have not looked into how your client behaves in this
respect.

Well. the important part of my response is the other paragraphs.
Content-Location can not be dropped from HTTP without making a major
mess of the rules on cache invalidations on negotiated content or
derived URLs.

Regards
Henrik

[Story Henry]

On 29 Nov 2006, at 14:05, Henrik Nordstrom wrote:

> ons 2006-11-29 klockan 13:41 -0800 skrev Roy T. Fielding:
>
>>     The value of Content-Location also defines the base URI for the
>>     entity.
>>
>> s/also defines/does not define/;
>>
>> Such a change would not effect current practice and would still allow
>> Content-Location to be useful for all of the other reasons it exists
>> (none of which are broken by IIS or MSIE because they don't author).
>
> Partly agreed as it's unlikely the header will ever get supported by
> clients in the current state of things, but please note it's also in
> RFC2396->RFC2110.
>
> There is no doubt that servers sending bad Content-Location is broken,
> and this in large due to clients not supporting it so server admins
> hasn't noticed they are sending bad Content-Location headers.

Could that be solved my creating a ERR method, so that clients could  
send feedback to servers at the resource they found wanting?

------------------
ERR /page0 HTTP...
...

Your Content-Location is broken see spec xyz
------------------



> It's worth noting that in many cases servers sending bad
> Content-Location headers is also sending bad Location headers, often
> seen if you drop the last / on a directory request etc...
>


> Regards
> Henrik

[stefan.eissing]

Anne,

would the change proposed by Roy, namely excluding Content-Location  
from any base URI calculation, solve the problems for browsers?

I am asking as it looks like possible approach to me and you did not  
comment on it.

Cheers,

Stefan

Am 29.11.2006 um 22:58 schrieb Anne van Kesteren:

>
> On Wed, 29 Nov 2006 22:41:11 +0100, Roy T. Fielding  
> <fielding@...> wrote:
>>> It basically can't be implemented by web browsers. See for  
>>> instance https://bugzilla.mozilla.org/show_bug.cgi?id=109553 ...  
>>> We've tried it as well, broke the web, and then backed it out again.
>>
>> No. It is pathetic that some vendors choose to drop features rather
>> than deploy version-specific workarounds, but not entirely  
>> unexpected.
>
> Vendors have tried and have tried to deploy workarounds. By  
> blacklisting/whitelisting servers etc. Didn't work out.
> [...]

[Julian Reschke]

Anne van Kesteren schrieb:

> On Wed, 29 Nov 2006 22:40:25 +0100, Julian Reschke
> <julian.reschke@...> wrote:
>> 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.
>
> I'm sure you read
> https://bugzilla.mozilla.org/show_bug.cgi?id=109553#c37 as well which
> suggests otherwise. Also, whether it's servers or clients that are
> broken doesn't really matter. The simple fact is that the header can't
> be supported.

Actually, the interesting information seems to be in
<https://bugzilla.mozilla.org/show_bug.cgi?id=238654>.

I'm very nervous, because other specs, such as RFC2518 (out since 1999)
and APP (new) use Content-Location, so I really don't see how it can be
dropped.

>> 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...
>
>  From my recollection we can't really implement it in any way.

It's late, any I may not have seen all the cases of breakage, but most
of them seem to involve private IPs and bogus port numbers. Both
problems will not occur when an absolute path is used.

Best regards, Julian

[Ian Hickson]

On Wed, 29 Nov 2006, Julian Reschke wrote:
>
> It's late, any I may not have seen all the cases of breakage, but most
> of them seem to involve private IPs and bogus port numbers. Both
> problems will not occur when an absolute path is used.

There are definitely absolute paths that are broken too, enough that it
makes implementing the header basically impossible in a Web browser. (I
was involved in both Opera's and Mozilla's attempts to implement this
header.)

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[Julian Reschke]

Ian Hickson schrieb:
> On Wed, 29 Nov 2006, Julian Reschke wrote:
>> It's late, any I may not have seen all the cases of breakage, but most
>> of them seem to involve private IPs and bogus port numbers. Both
>> problems will not occur when an absolute path is used.
>
> There are definitely absolute paths that are broken too, enough that it
> makes implementing the header basically impossible in a Web browser. (I
> was involved in both Opera's and Mozilla's attempts to implement this
> header.)

OK, thanks for letting us know.

Now what? There are use cases where it doesn't fail (WebDAV, for
instance), and new protocols using it (APP). And cache handling would be
affected, so I don't see how it can be dropped.

So this seems to make it a feature that frequently is used the wrong
way, and therefore isn't supported by the mainstream browsers. But then,
this can be said about other features as well (dare I say "Vary"?).

Best regards, Julian

[Henrik Nordstrom-5]

ons 2006-11-29 klockan 23:30 +0100 skrev Julian Reschke:

> It's late, any I may not have seen all the cases of breakage, but most
> of them seem to involve private IPs and bogus port numbers. Both
> problems will not occur when an absolute path is used.

Having worked with setups creating this problem all in all it's possible
variants. Here follows a breakdown of what is causing bogus
[Content-]Location headers:

Bad host name: Server configured with a bad server name and not
reflecting the Host header back in generated URLs.

Bad port: Some device in front of the server remaps the request port
(i.e. NAT) without the server being aware or capable of handling the
situation.

Bad absolute path, bad protocol, or any of the above: A reverse proxy
remapping requests in the URL-namespace without properly undoing the
mappings in returned [Content-]Location headers.

Regards
Henrik

[Yngve N. Pettersen (Developer Opera Software ASA)]

On Wed, 29 Nov 2006 22:40:25 +0100, Julian Reschke <julian.reschke@...>  
wrote:

>
> Anne van Kesteren schrieb:
>>  It basically can't be implemented by web browsers. See for instance  
>> https://bugzilla.mozilla.org/show_bug.cgi?id=109553 ... 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:

http://www.talk.com/talk/home.do : Content-Location is  
http://www.talk.com/talk/jsp/home.jsp . 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?

http://www.lilypaddayspa.net/: Content-Location is  
http://www.lilypaddayspa.net/lily/index.htm . The webpage contain a  
relative reference to images/headerbutton.jpg . If resolved to  
http://www.lilypaddayspa.net/lily/images/headerbutton.jpg you get a 404.

Absolute path:

http://forums.oracle.com/forums/category.jspa?categoryID=19 :  
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.

--
Sincerely,
Yngve N. Pettersen
 
********************************************************************
Senior Developer                     Email: yngve@...
Opera Software ASA                   http://www.opera.com/
Phone:  [phone]              Fax:    [phone]
********************************************************************

[Henrik Nordstrom-5]

ons 2006-11-29 klockan 23:43 +0100 skrev Julian Reschke:

> So this seems to make it a feature that frequently is used the wrong
> way, and therefore isn't supported by the mainstream browsers. But then,
> this can be said about other features as well (dare I say "Vary"?).

Exactly to the point I think.

So it's best left as it is. With major browsers not implementing it
today site authors is unlikely to depend today on having it implemented,
and maybe over time things will improve to the point that it actually
can be enabled in the browsers gradually allowing site authors to start
taking advantage of the feature to optimize their URL-namespace. Quite
likely will if the meaning and purpose of Content-Location gets some
awareness among CMS and reverse proxy authors which WebDAV has a good
chance of accomplishing.

It's not like the migration path is that difficult on the server side
when accounting for both client types (the ones caring and the ones
ignoring).

Regards
Henrik

[Julian Reschke]

Yngve N. Pettersen (Developer Opera Software ASA) schrieb:
>> 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.
> ...

Understood. But please understand I said "majority" not "all". If we'd
remove all HTTP features that *some* sites get wrong, where would that end?

And, btw, would RoyF's suggested change
(<http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/0192.html>)
fix the problem for you?


Best regards, Julian

[Henrik Nordstrom-2]

ons 2006-11-29 klockan 23:54 +0100 skrev Yngve N. Pettersen (Developer
Opera Software ASA):

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

I don't share this view. Adding new names for an existing header is not
a solution to the problem of people not following specifications.

The only way forward it to gradually collectively work towards getting
Content-Location understood. It's not an impossible war, it's about
educating the site/server owners/designers about the HTTP protocol and
why doing things the wrong way is hurting themselves in the long run.

This war has already been fought with the Vary header, and things has
improved considerably over the years to the point that today you can
almost trust Vary. That war is now moving forward to also raise the
level of understanding of ETag.

It will take time and some energy, but is not impossible. A large part
is to identify the actual sources of the errors, then to try to ensure
that there is some efforts taken in reducing the knowledge gap.

Regards
Henrik

[Henrik Nordstrom-5]

tor 2006-11-30 klockan 00:06 +0100 skrev Julian Reschke:

> And, btw, would RoyF's suggested change
> (<http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/0192.html>)
> fix the problem for you?

After some serious consideration on the implications I think this change
should at most be done a note documenting that many user-agents ignore
Content-Location, maybe angled as an HTTP/1.0 relic. Content-Location
did not exists in HTTP/1.0, so any server wanting to support HTTP/1.0
clients can not rely on the user-agents understanding Content-Location
for establishing the base URL.

I think it's a good feature to keep, allowing very nice optimizations of
the URL-namespace if used correctly for defining the base URL, and can
already find very good use outside the browsing use case of HTTP. Just
sad there is too many sites not sending correct headers making it hard
to deploy in the browsers.

The specifications as they are is pretty clear on this issue, even if
it's not repeated all over the place. Quite unlike many other situations
where implementations gets things wrong.

Regards
Henrik