RE: Deprecate Content-Location? (was RE: "Variant" language in Content-Location (Issue 109))

ons 2008-08-06 klockan 09:33 -0500 skrev Brian Smith:
> I agree that if it were actually implemented in an interoperable way, it
> would be very useful. However, there is basically no interoperability for
> the Content-Location header.

I disagree. Yes, there is some servers not ending out correct
Content-Location, but save for the base-URI part there is no real
interoperability issues.

The unique URI meaning of Content-Location is not of importance to
browsing applications, as for browing you generally want to stick to the
request-URI to continue benefit from whatever selection or versioning
logics the server may apply there.

Content-Location comes into importance in applications going beyond
simple browsing, i.e
  - Authoring
  - Archiving
  - Versioning
and also to some degree
  - Caching (which is a subset of archiving)

For servers wanting to support these applications providing a correct
Content-Location becomes important, just as it becomes important to
provide correct support for related methods beyond GET/HEAD.


> In some cases, that means Content-Location can only be Request-URI (due to
> links like "#fragment"). Anyway, I am not suggesting that Content-Location
> be removed; that cannot be done. I am just suggesting that the advise in the
> specification should change from encouraging its use to discouraging its
> use.

Why?

Deprecating the Base-URI part is one thing, but whats wrong with the
rest?

I still do not get what the fuzz is about here. The definition of
Content-Location is very clear when placed in the content model HTTP is
defined for.

I'd say the real issue probably is that 2616 isn't very clear on the
content model. There is related RFCs documenting the content model of
HTTP is documented correctly, unfortunately it's number escapes me at
the moment..

> Like I said in the previous message, if it doesn't affect conformance then
> it should be removed because it adds confusion.

Understanding the intended content model of HTTP affects confomance as
it's very easy to get things like ETag, Content-Location, variant,
cache, Vary, and even Request-URI wrong without being interpreted in
that context.

The Content-Location text is only a little muddled because of potential
security implications if used wrongly, but it's intended meaning is very
clear from the text. And I also argue that it's intended use is equally
clear including how to transition from a GET of a Request-URI directly
to a conditional PUT to Content-Location for authoring that specific
variant.

Regards
Henrik

Received on Thursday, 7 August 2008 14:21:28 UTC