Subject: NEW ISSUE: Drop Content-Location

From: "Anne van Kesteren" <[email-masked]>
Date: Wed, 29 Nov 2006 21:24:29 +0100

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

---

From: Julian Reschke <[email-masked]>
Date: Wed, 29 Nov 2006 22:40:25 +0100

Anne van Kesteren schrieb:
> https://bugzilla.mozilla.org/show_bug.cgi?id=109553 ... We've tried it 
> as well, broke the web, and then backed it out again.
> 

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

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 29 Nov 2006 13:41:11 -0800

On Nov 29, 2006, at 12:24 PM, Anne van Kesteren wrote:
> 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

---

From: "Anne van Kesteren" <[email-masked]>
Date: Wed, 29 Nov 2006 22:44:29 +0100

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

> path. That should still cover the majority of the use cases...

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

---

From: Henrik Nordstrom <[email-masked]>
Date: Wed, 29 Nov 2006 22:50:01 +0100

> 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

---

From: "Anne van Kesteren" <[email-masked]>
Date: Wed, 29 Nov 2006 22:52:18 +0100

On Wed, 29 Nov 2006 22:50:01 +0100, Henrik Nordstrom <[email-masked]>  
wrote:
>> as

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

---

From: "Anne van Kesteren" <[email-masked]>
Date: Wed, 29 Nov 2006 22:58:52 +0100

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

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

---

From: Henrik Nordstrom <[email-masked]>
Date: Wed, 29 Nov 2006 23:05:57 +0100

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

---

From: Henrik Nordstrom <[email-masked]>
Date: Wed, 29 Nov 2006 23:12:38 +0100

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

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

---

From: Henry Story <[email-masked]>
Date: Wed, 29 Nov 2006 14:18:54 -0800

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

---

From: Stefan Eissing <[email-masked]>
Date: Wed, 29 Nov 2006 23:19:36 +0100

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  
> <[email-masked]> 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.
>>
> [...]

---

From: Julian Reschke <[email-masked]>
Date: Wed, 29 Nov 2006 23:30:06 +0100

Anne van Kesteren schrieb:
> On Wed, 29 Nov 2006 22:40:25 +0100, Julian Reschke 
> <[email-masked]> wrote:
>> 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...
> 

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

---

From: Ian Hickson <[email-masked]>
Date: Wed, 29 Nov 2006 22:32:36 +0000 (UTC)

> 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.   `._.-(,_..'--(,_..'`-.;.'

---

From: Julian Reschke <[email-masked]>
Date: Wed, 29 Nov 2006 23:43:34 +0100

> was involved in both Opera's and Mozilla's attempts to implement this 

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

---

From: Henrik Nordstrom <[email-masked]>
Date: Wed, 29 Nov 2006 23:51:43 +0100

> 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

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Wed, 29 Nov 2006 23:54:10 +0100

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

> 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: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 30 Nov 2006 00:01:04 +0100

> 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

---

From: Julian Reschke <[email-masked]>
Date: Thu, 30 Nov 2006 00:06:26 +0100

> 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

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 30 Nov 2006 00:12:24 +0100

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

> a Base URL replacement. If such functionality is desired, an entirely new  

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

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 30 Nov 2006 00:25:50 +0100

> (<http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/0192.html>) 

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

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 30 Nov 2006 00:29:40 +0100

> send feedback to servers at the resource they found wanting?

Interesting idea, but getting this deployed is probably about as hard as
getting the Content-Location headers fixed..

also does not solve the problem as browsers won't enable the feature
(Content-Location) until it works reasonably well so they won't notice
the error to report, and site owners won't correct the error until there
is sufficient deployment of browsers making their site fail.. (or at
least sufficient complaints that their server is broken).

Regards
Henrik

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Thu, 30 Nov 2006 00:34:22 +0100

> Understood. But please understand I said "majority" not "all". If we'd

Well, this is a case where it can't work for one use case: Web surfing

> remove all HTTP features that *some* sites get wrong, where would that  

Unfortunately, when you are dealing with a large number of websites  
implementing something wrong you reach a point where you have to decide if  
it is possible and realistic to work around the problem by detecting the  
existence of the problem, or drop the feature. For Content-Location  
working around it was not realistic.

Off-topic example: For HTTP pipelining we've implemented a lot of  
heuristics to handle bad servers, and there are still servers (from major  
vendors), that cause problems I'm currently unable to work around.

> (<http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/0192.html>)  

Not sure. The way I read it, it removes the one thing we were using it  
for: A Base URL replacement.

It may very well be that Content-Location can be useful in some  
applications, but ordinary web surfing is not such an application.

-- 
Sincerely,
Yngve N. Pettersen

---

From: "Mark Baker" <[email-masked]>
Date: Wed, 29 Nov 2006 21:33:35 -0500

> seems quite open to incremental additions and changes.

Sure, but there are limits to HTTP extensibility.  One limit is that
you can't introduce extensions which change the meaning of the message
such that existing agents would interpret it incorrectly.
Content-Base is such an extension, hence the need for the version rev
to protect those agents.

Mark.

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 30 Nov 2006 04:11:30 +0100

> Content-Base is such an extension, hence the need for the version rev

Bumping the version won't protect those agents. Version numbers is
mainly a compliance specification thing.

A change which would make existing servers or clients non-compliant with
the specifications need a version bump, but still requires careful
thought on interoperability as the version number is not useful at the
protocol level, only compliance specification level.

An related example. For interoperability with HTTP/1.0, servers should
not assume Content-Location is universally understood and should allow
URLs to be resolved reasonably (but maybe not optimal) even if
Content-Location is ignored. This even if the request received is
HTTP/1.1 as that only indicates the compliance level of the last hop,
not the compliance level of the actual user-agent.

But to be honest I don't see how adding yet another header solves any of
the problem. There will again most certainly be plenty of servers
deployed not sending this new header correct, and adding the new header
does not solve the reasons why servers has problems sending correct
Content-Location headers.  Only hope says that client deployment of this
new feature will be sufficiently quick to bring awareness of the feature
before too many servers gets it wrong again, and to me that's not a good
reason for a specification change.

Regards
Henrik

---

From: "Anne van Kesteren" <[email-masked]>
Date: Thu, 30 Nov 2006 09:43:12 +0100

> remove all HTTP features that *some* sites get wrong, where would that  

I've no idea. In order to create a specification for the web that's  
actually useful you have to make sure it's being implemented (and can be  
implemented interoperably) by clients that are widely deployed. Say, 30%  
of the market. To get there you probably need a lot of testcases and get  
feedback on implementation problems in popular user agents and change the  
specification when it appears that something is broken.

---

From: Yves Lafon <[email-masked]>
Date: Thu, 30 Nov 2006 16:33:54 +0100 (MET)

> to deploy in the browsers.

In the case of editing a negotiated resource, CL might be very useful, so 
ruling out CL entirely because a particular point of 14.14 and the lack of 
implementation of it in 99% of the browsers is not wanted.
Roy's approach to remove only the part setting the base of the document 
would work (although it would make conformant brosers and sites 
non-conformant, but that's another story).

-- 
Yves Lafon - W3C
"Baroula que barouleras, au tiéu toujou t'entourneras."

---

From: Yves Lafon <[email-masked]>
Date: Thu, 30 Nov 2006 16:35:10 +0100 (MET)

On Thu, 30 Nov 2006, Yngve N. Pettersen (Developer Opera Software ASA) wrote:

> It may very well be that Content-Location can be useful in some applications, 
> but ordinary web surfing is not such an application.

False, it may be very useful in ordinary web surfing, only the lack of 
implementation (and the huge number of badly configured servers) forbid 
using this capability, which is something completely different.

---

From: "Mike Dierken" <[email-masked]>
Date: Thu, 30 Nov 2006 15:37:52 -0800

This may be similar to the situation with validation of HTML - tools
exist but not all authors use them.
Rather than changing a protocol definition, maybe writing a tool that
interested site authors can use would be easier to build and deliver.