Subject: "Variant" language in Content-Location (Issue 109)

From: Julian Reschke <[email-masked]>
Date: Tue, 05 Aug 2008 21:54:24 +0200

Hi,

I was staring at the definition of Content-Language, and trying to 
figure out how to rephrase it avoiding the term "variant" (as discussued 
in <http://wiki.tools.ietf.org/wg/httpbis/trac/ticket/109>):

RFC 2616 says:

    The Content-Location entity-header field MAY be used to supply the
    resource location for the entity enclosed in the message when that
    entity is accessible from a location separate from the requested
    resource's URI. A server SHOULD provide a Content-Location for the
    variant corresponding to the response entity; especially in the case
    where a resource has multiple entities associated with it, and those
    entities actually have separate locations by which they might be
    individually accessed, the server SHOULD provide a Content-Location
    for the particular variant which is returned. -- 
<http://tools.ietf.org/html/rfc2616#section-14.14>

Comments:

- the first "MAY" seems to be useless and actually distracting ("may be 
used", "can be used" or "is used" would be just fine)

- "...when that entity is accessible from a location separate from the 
requested resource's URI" -- can this be simplified to "when that entity 
is accessible from a location separate from the request-URI"? Or am I 
missing something here?

- then it goes on saying server "SHOULD" return the header, but then 
"SHOULD return especially" in some special cases -- but there was 
already an unconditional SHOULD without that condition.

Part of this confusion seems to be the result of trying to BCP14fy what 
RFC2068 said (which had the first "SHOULD" in lower case).

So, looking at RFC 2068:

    The Content-Location entity-header field may be used to supply the
    resource location for the entity enclosed in the message. In the case
    where a resource has multiple entities associated with it, and those
    entities actually have separate locations by which they might be
    individually accessed, the server should provide a Content-Location
    for the particular variant which is returned. In addition, a server
    SHOULD provide a Content-Location for the resource corresponding to
    the response entity. -- 
<http://tools.ietf.org/html/rfc2068#section-14.15>

This looks a bit better, except for the last sentence:

"In addition, a server SHOULD provide a Content-Location for the 
resource corresponding to the response entity."

...which I frankly do not understand -- what does it say what hasn't 
been said before?

So if I had to rewrite this I would make it just:

    The Content-Location entity-header field may be used to supply the
    resource location for the entity enclosed in the message. In the case
    where a resource has multiple entities associated with it, and those
    entities actually have separate locations by which they might be
    individually accessed, the server SHOULD provide a Content-Location
    for the particular variant which is returned.

(BCP14fying the should, dropping the last sentence)

Feedback appreciated,

Julian

---

From: "Brian Smith" <[email-masked]>
Date: Tue, 5 Aug 2008 18:33:13 -0500

Julian Reschke wrote:
>     resource location for the entity enclosed in the message. 
>     In the case where a resource has multiple entities associated with 
>     it, and those entities actually have separate locations by which
>     they might be individually accessed, the server SHOULD provide a 
>     Content-Location for the particular variant which is returned.
> 

1. The message might not contain an entity (e.g. if the request is a HEAD or
if the response code is 204 No Content), so "entity enclosed in the message"
is not really correct.

2. An entity is not the same thing as a variant, so you cannot substitute
"entity" for "variant". A variant is identified by (Resource-URI, Vary) or
(Resource-URI, Content-Location) and an entity is identified by
(Resource-URI, ETag) or (Resource-URI, Last-Modified, Content-Location). In
other words, there is a one-to-many relationship between variants and
entities (see the section that talks about invalidating cache entries based
on Content-Location).

3. The RFC 2616 language says that Content-Location SHOULD be provided in
every case. Your change only says Content-Location should be required in the
special case that begins "especially" in RFC 2616. So, it doesn't mean the
same thing.

4. There are important cases where the server SHOULD NOT include the
Content-Location header. In reality, a server can't safely include the
Content-Location header unless it knows that all relative URI references in
the entity representing the variant will resolve to the same URIs that they
would resolve to if the Content-Location was not provided (because almost
all clients ignore Content-Location when resolving relative URIs.)
Basically, it is only safe to send the Content-Location header in limited
circumstances. This is contradictory to the "server SHOULD provide a
Content-Location" advice.

5. What does "might be individually accessed" mean? As far as cache
validation is concerned (which is the only time Content-Location is used in
the protocol itself), the Content-Location doesn't have to be accessible.
That whole condition can be removed since it is meaningless.

- Brian

---

From: "Robert Brewer" <[email-masked]>
Date: Tue, 5 Aug 2008 16:45:03 -0700

> used", "can be used" or "is used" would be just fine)

Totally agree.

> is accessible from a location separate from the request-URI"? Or am I

Also sounds good.

> (BCP14fying the should, dropping the last sentence)

Going on an anti-verbosity tear:

    The Content-Location entity-header field supplies a location
    for the returned entity that is separate from the Request-URI.
    A server SHOULD provide a Content-Location whenever a resource
    has multiple entities with separate locations.

Robert Brewer
[email-masked]

---

From: Stefan Eissing <[email-masked]>
Date: Wed, 6 Aug 2008 09:20:10 +0200

Am 05.08.2008 um 21:54 schrieb Julian Reschke:
> [...]

I totally agree.

Is there a need to express the client's expectation that the "Content- 
Location" URL will only have a single entity associated with it? Or  
is a client expected to follow "Content-Location"s for a number of  
times?

//Stefan

--
<green/>bytes GmbH, Hafenweg 16, D-48155 Münster, Germany
Amtsgericht Münster: HRB5782

---

From: Julian Reschke <[email-masked]>
Date: Wed, 06 Aug 2008 09:55:18 +0200

> if the response code is 204 No Content), so "entity enclosed in the message"

That's true (and the same text is in 2616). Care to propose something else?

> entities (see the section that talks about invalidating cache entries based

The current plan for Issue 109 is to get rid of the term "variant", and 
to make "representation" and "entity" equivalent 
(<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/109>). There's a 
*separate* issue for "requested variant", which is issue 69 
(<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/69>).

> special case that begins "especially" in RFC 2616. So, it doesn't mean the

Yes, that's intentional and reflects what RFC 2068 said. I think the 
change in RFC 2616 was incorrect (overzealous conversion to BCP 14 
keywords).

So do you think that servers SHOULD return a Content-Location even when 
only one entity is associated?

> Content-Location" advice.

That sounds like a separate and new issue.

> That whole condition can be removed since it is meaningless.

What's the point in supplying a Content-Location, if nobody can access it?

BR, Julian

---

From: Jamie Lokier <[email-masked]>
Date: Wed, 6 Aug 2008 13:24:55 +0100

> What's the point in supplying a Content-Location, if nobody can access it?

Could it be like XML namespace URIs - to provide a unique identifier
that is not necessarily meant to be an accessible resource?

-- Jamie

---

From: Julian Reschke <[email-masked]>
Date: Wed, 06 Aug 2008 14:47:49 +0200

> that is not necessarily meant to be an accessible resource?

In theory, yes. Does this happen in practice? Do we want it to happen in 
practice?

BR, Julian

---

From: "Brian Smith" <[email-masked]>
Date: Wed, 6 Aug 2008 08:09:59 -0500

Julian Reschke wrote:
> >>   The Content-Location entity-header field may be used 
> >>   to supply the resource location for the entity
> >>   enclosed in the message. 
> >>   In the case where a resource has multiple entities 
> >>   associated with it, and those entities actually have
> >>   separate locations by which they might be individually
> >>   accessed, the server SHOULD provide a Content-Location

> > 1. The message might not contain an entity (e.g. if the 
> > request is a HEAD or if the response code is 204 No Content),
> > so "entity enclosed in the message" is not really correct.
> 

If a response contains an entity with a Content-Location header, then the
Content-Location identifies a resource, and the response entity is a
representation of that resource. In responses to GET and HEAD requests the
Content-Location identifies the selected variant. 

> > 2. An entity is not the same thing as a variant, so you cannot 
> > substitute "entity" for "variant". A variant is identified by 
> > (Resource-URI, Vary) or (Resource-URI, Content-Location) 
> > and an entity is identified by (Resource-URI, ETag) or
> > (Resource-URI, Last-Modified, Content-Location). In other
> > words, there is a one-to-many relationship between variants
> > and entities (see the section that talks about 
> > invalidating cache entries based on Content-Location).
> 
> The current plan for Issue 109 is to get rid of the term 
> "variant", and to make "representation" and "entity" 
> equivalent 

I know. What I am trying to say is that plan doesn't work because "entity"
and "variant" mean two different things. I think "entity" could replace
"representation" but it cannot replace "variant." The language that
describes cache invalidation based on Content-Location makes it clear that
Content-Location isn't supposed to identify a specific entity. Otherwise,
Content-Location would be functionally equivalent to ETag. If you think
about it in VCS terms, then a variant is a branch of a resource, and an
entity is a particular version of a variant. At any particular time, there
can be many variants of a resource and each variant has one entity that
describes it at that point of time. Over time, a variant will be described
by multiple entity as the variant changes.

I don't really see the motivation for i109. If the specification is going to
become much clearer by such a change, then I am all for it. But, if "entity"
is going to lose its precise meaning or be overloaded with multiple meanings
then how is that an improvement?

> > 3. The RFC 2616 language says that Content-Location SHOULD 
> >    be provided in every case. Your change only says
> >    Content-Location should be required in the special case
> >    that begins "especially" in RFC 2616. So, it doesn't mean
> >    the same thing.
> 
> Yes, that's intentional and reflects what RFC 2068 said. I 
> think the change in RFC 2616 was incorrect (overzealous 
> conversion to BCP 14 keywords).
> 
> So do you think that servers SHOULD return a Content-Location 
> even when only one entity is associated?

IF Content-Location is going to live on then I agree that the RFC 2068-like
definition makes more sense. Basically that if the response contains a Vary
header then the entity should have a Content-Location header.

> > 4. There are important cases where the server SHOULD NOT 
> > include the Content-Location header. In reality, a server
> > can't safely include the Content-Location header unless it
> > knows that all relative URI references in the entity
> > representing the variant will resolve to the same URIs
> > that they would resolve to if the Content-Location was not 
> > provided (because almost all clients ignore Content-Location when 
> > resolving relative URIs.) Basically, it is only safe to send the 
> > Content-Location header in limited circumstances. This is 
> > contradictory to the "server SHOULD provide a 

 I am not sure that Content-Location can even be defined in a useful way due
to this problem. The reason I bring it up here is that "Servers SHOULD NOT
include a Content-Location header in the response entity" reflects the lack
of support for Content-Location in most clients, but that is the opposite of
your suggested change.

> > validation is concerned (which is the only time Content-Location is 
> > used in the protocol itself), the Content-Location doesn't 
> have to be accessible.

Caches uses Content-Location is to identify the variant (not entity--that is
what ETag does) so that they can invalidate multiple cache entries at once.
That is the only use of Content-Location in the protocol itself. Since the
cache doesn't need to issue a request to invalidate those entries, the
resource at Content-Location doesn't have to be accessible. The only other
use of Content-Location in HTTP is to resolve relative URIs in the response
entity, and the resource doesn't have to be "accessible" for that either.

If the "might be individually accessed" condition is important then it needs
to be clarified so that implementations know what they are supposed to do to
meet the condition. But, I don't think the condition adds any value which is
why I suggest that it is simply removed.

But, again, I think we should first decide if the use of Content-Location
should ever be encouraged at all given how problematic it is.

- Brian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 06 Aug 2008 15:32:01 +0200

Brian Smith wrote:
> ...
> ...

That doesn't the HEAD issue either, I think. Also it's contrary to our 
goal not to use "variant" anymore. (see below)

> and "variant" mean two different things. I think "entity" could replace

Do they?

RFC 2616 says about "variant":

"A resource may have one, or more than one, representation(s) associated 
with it at any given instant. Each of these representations is termed a 
`varriant'. Use of the term `variant' does not necessarily imply that 
the resource is subject to content negotiation."

So a variant *is* a representation. (And I think we have decided earlier 
that there's really no distinction between "representation" and "entity" 
either).

> Content-Location would be functionally equivalent to ETag. If you think

Although Content-Location identifies an entity, that doesn't mean that 
that entity can't change over time.

> by multiple entity as the variant changes.

I think we agree on this.

> then how is that an improvement?

The issues we want to solve are:

- we have three terms that mean either the same or very similar thing 
(depending whom you ask), and people *are* confused

- the definition of "representation" is broken ("An entity included with 
a response that is subject to content negotiation, ...) -- it's 
definitively not used that way; and I don't see why we would need a 
special term for that case

- we have no definition of "requested variant", and that affects the 
ETag discussions.

There may be more, but these are my favorites.

> header then the entity should have a Content-Location header.

Yes (unless the server did not send Vary because of the other issues 
with UA handling of that one).

> ...
> ...

There are definitively other uses, such as authoring a specific variant. 
Maybe not clear from RFC 2616, but they exist anyway.

> ...

I must admit that I'm not aware of any problems with Content-Location in 
practice (besides the issues raised months ago wrt the base URI).

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 06 Aug 2008 15:42:02 +0200

Stefan Eissing wrote:
> Is there a need to express the client's expectation that the 
> "Content-Location" URL will only have a single entity associated with 
> it? Or is a client expected to follow "Content-Location"s for a number 
> of times?

I wouldn't want to encourage that case, but would anything break if that 
happened?

BR, Julian

---

From: Yves Lafon <[email-masked]>
Date: Wed, 6 Aug 2008 09:45:43 -0400 (EDT)

> header then the entity should have a Content-Location header.

And also when you do a GET/HEAD on http://www.exemple.org/foo/ (as you may 
want to edit the "myniceindexpage.html" page :) ).

>>> Content-Location" advice.

Well, it would be nice to have in the browser a way to figure out that CL 
has been used, and wrongly or not (like CL: http://internal:8080/...) so 
that site designers would have a chance to get this right.

CL would be used to create latest/archived version of the same content 
without having to rewrite all the internal links, so it's a pity 
implementors (of both servers/reverse proxies/browser) didn't got it 
right.

> of support for Content-Location in most clients, but that is the opposite of

CL _is_ useful (not for popular browsers, but those are not the only UAs), 
so it would break things to remove it. It seems that the best we can do is 
document that the state of implementation is such that the only safe way 
to use CL is when it resolves the relative links as the request URI...

> why I suggest that it is simply removed.

I read this as "at the time of the request, it was the URI where "it might 
be ...", however nothing force the client to access it there, nor the 
server to make it available. The text looks fine as is, as it sets no 
condition on the implementation.

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

---

From: "Brian Smith" <[email-masked]>
Date: Wed, 6 Aug 2008 09:26:58 -0500

Julian Reschke wrote:
> Brian Smith wrote:
> > I know. What I am trying to say is that plan doesn't work 
> > because "entity" and "variant" mean two different things.
> > I think "entity" could replace
> 
> Do they?
> 
> "A resource may have one, or more than one, representation(s) 
> associated with it at any given instant. Each of these 
> representations is termed a `varriant'. Use of the term 
> `variant' does not necessarily imply that the resource is 
> subject to content negotiation."

> So a variant *is* a representation. (And I think we have 
> decided earlier that there's really no distinction between 
> "representation" and "entity" either).

I agree, "representation" and "entity" are the same. 

> Although Content-Location identifies an entity, that doesn't 
> mean that that entity can't change over time.

That is the part that I disagreed with because I've always thought of
"entity" as describing an immutable value. However, I guess entities are
immutable in RFC 2616 just because "entity" is used to describe parts of
messages only, and messages are immutable. I guess as long as writers are
careful to differentiate between "entity" and "version of an entity" when
the distinction matters, things can work. But, "version of an entity" isn't
really clearly defined in RFC 2616 either.

That is why I think it is clearer to say "variant" instead of "entity" when
describing things that potentially change over time, and say "entity"
instead of "verssion/instance/value of an entity" to describe particular
values of such things. That would allow the removal of the terms
"representation," and "entity value", "versions of an entity", and
"instances of that entity". (Incidentally, "document" is another term that
should be removed.) 

> > If the "might be individually accessed" condition is 
> > important then it needs to be clarified so that
> > implementations know what they are supposed to do to
> > meet the condition. But, I don't think the condition 
> > adds any value which is why I suggest that it is simply
> > removed.

If the "might be individually access" condition is going to stay in, then
please add an explanation of how to conform to that requirement. If it
doesn't affect conformance then it doesn't make sense to keep it.

> > But, again, I think we should first decide if the use of 
> > Content-Location should ever be encouraged at all given how 
> > problematic it is.
> > ...
> 
> I must admit that I'm not aware of any problems with 
> Content-Location in practice (besides the issues raised 
> months ago wrt the base URI).

The base URI issue makes Content-Location dangerous to use. The only time it
is safe to use Content-Location is when the Content-Location is exactly the
same as the Request-URI (because of relative URI references like
"#fragment"), or when the response entity doesn't contain any relative URIs.
However, if you limit Content-Location to be the same as the Request-URI
then it can no longer identify individual variants of the resource, which is
its main purpose. As a rule of thumb, it is safer to omit the
Content-Location than it is to include it. That is why I think some language
like "Servers SHOULD NOT include a Content-Location header in responses
[unless...]" is important.

Another problem with Content-Location is that some implementations
apparently use it to edit individual variants of a resource, but that use of
Content-Location isn't well-defined in RFC 2616, there are security
considerations that make it very difficult to define in a useful way,
describing how that works would be a lot of work, and there is no evidence
of interoperability for this use of the header anyway.

- Brian

---

From: "Brian Smith" <[email-masked]>
Date: Wed, 6 Aug 2008 09:33:03 -0500

Yves Lafon wrote:
> And also when you do a GET/HEAD on 
> http://www.exemple.org/foo/ (as you may want to edit the 
> "myniceindexpage.html" page :) ).

I understand that use case, but HTTP doesn't specify how that works at all.

> Well, it would be nice to have in the browser a way to figure 
> out that CL has been used, and wrongly or not (like CL: 
> http://internal:8080/...) so that site designers would have a 
> chance to get this right.
> 
> CL would be used to create latest/archived version of the 
> same content without having to rewrite all the internal 
> links, so it's a pity implementors (of both servers/reverse 
> proxies/browser) didn't got it right.

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.

> CL _is_ useful (not for popular browsers, but those are not 
> the only UAs), so it would break things to remove it. It 
> seems that the best we can do is document that the state of 
> implementation is such that the only safe way to use CL is 
> when it resolves the relative links as the request URI...

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.

> I read this as "at the time of the request, it was the URI 
> where "it might be ...", however nothing force the client to 
> access it there, nor the server to make it available. The 
> text looks fine as is, as it sets no condition on the implementation.

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

- Brian

---

From: "Brian Smith" <[email-masked]>
Date: Wed, 6 Aug 2008 16:11:38 -0500

Brian Smith wrote:
> Julian Reschke wrote:
> > Although Content-Location identifies an entity, that 
> > doesn't mean that that entity can't change over time.
...
> That is why I think it is clearer to say "variant" instead of 
> "entity" when describing things that potentially change over 
> time, and say "entity"
> instead of "verssion/instance/value of an entity" to describe 
> particular values of such things. That would allow the 
> removal of the terms "representation," and "entity value", 
> "versions of an entity", and "instances of that entity". 
> (Incidentally, "document" is another term that should be removed.) 

I would like to take this suggestion one step further:

* Keep "entity" as I described it above; a fixed set of header values with a
fixed body.

* Replace all of the following terms with "entity": "entity value,"
"version(s) of an entity," "instances of that entity," "representation",
"variant," and "document".

* Don't define any term for what we usually think of when we say "variant".
In other words, remove the whole *concept* of mutable representations of
resources. Instead, operations that change resources would modify the set of
(immutable) entities that represent that resource.

Here is my alternate proposal for the definition of Content-Location
(completely replacing 14.14):

   6.7.  Content-Location

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

           Content-Location = "Content-Location" ":"
                             ( absoluteURI | relativeURI )

       Servers MAY ignore the Content-Location header of
       any PUT or POST request entity. Otherwise,
       applications SHOULD use an entity's Content-Location
       value as the base URI when resolving URI references
       in the entity. However, in practice, most applications
       ignore this requirement. To maximize interoperability,
       entities SHOULD NOT have a Content-Location header
       if the Content-Location header would have any effect
       on the resolution of any URI references in the entity.

       The Content-Location value of a response entity is not
       a replacement for the original request-URI.

       Previous versions of this specification recommended
       the use of Content-Location to identify the individual
       "variants" of a resource. Applications MAY continue
       to do so, but the details of this usage are undefined
       by this specification (just as they were left 
       undefined in previous versions). 
       
And then move the following statement to the 
Content-Location paragraph of part 6, section 8:

       A cache cannot assume that an entity with a
       Content-Location different from the URI used to retrieve
       it can be used to respond to later requests on that
       Content-Location URI. 

Thoughts?

- Brian

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 07 Aug 2008 15:24:44 +0200

> only one entity is associated?

The rule to use there is if there is more than one Request-URI which can
be used to access the resource. If there is only a single Request-URI
which can be used for requesting that resource (or variant thereof if
the resource is varying) then Content-Location is meaningless.

> That sounds like a separate and new issue.

Not really new.. see earlier discussions about deprecating
Content-Location, they all circulate around this issue..

> What's the point in supplying a Content-Location, if nobody can access it?

The point of Content-Location is to provide THE unique URI on which this
specific resource (variant) can be accessed. The cache invalidation
rules is a deduction from this fact, and so is the use of
Content-Location as a variant identifier.

Servers giving Content-Location URIs which isn't accessible is clearly
not doing the right thing. 

Servers not wanting to provide unique URIs for variants of a the
resource at the request-URI or transformed request-URIs should not sent
Content-Location.

What I mean by transformed request-URI is when the actual resource-URI
is different from request-URI. I.e. if there is "/index.html.gz" on the
server and all (or at least more than one) of "/" "/index", "/index/",
"/index.html", "/index.gz" and "/index.html.gz" can be used as
request-URI when requesting this resource.

Note: ETag serves the job of being an identifier with no URI
implications. There is absolutely no point in degrading the
identification properties of Content-Location to that of ETag.

Regards
Henrik

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 07 Aug 2008 15:36:18 +0200

> > and "variant" mean two different things. I think "entity" could replace

2616 is inconsistent about the use of the two, so it's hard to say.. but
my mental picture of the two places entity at the protocol message level
with variant at a more semantical level.

It's an important distinction when talking about other messages than 200
responses to HEAD/GET.

Regards
Henrik

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 07 Aug 2008 16:22:23 +0200

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

> specification should change from encouraging its use to discouraging its

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

> 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

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 07 Aug 2008 16:25:38 +0200

> is a client expected to follow "Content-Location"s for a number of  

It's a protocol expectation as well, very visible in the cache model, so
yes if people really think this can be misunderstood then yes it should
be clarified that the Content-Location URI SHOULD NOT be a negotiated
resource.

(it doesn't need to be a MUST imho)

Regards
Henrik

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 07 Aug 2008 16:31:56 +0200

> I wouldn't want to encourage that case, but would anything break if that 

The cache model of HTTP assumes that Content-Location is unique per
variant of the request-URI, which kind of implies that the
Content-Location URI is not a negotiated resource. For each Request-URI
Content-Location has the same uniqueness requirement across the variants
(but not versions) as ETag.  ETag is also version unique..

And when Content-Location is placed in the original HTTP content model
then it's very clear.. Content-Location is a direct unique reference URI
to a specific resource object with no negotiation or transformation.

Regards
Henrik

---

From: "Brian Smith" <[email-masked]>
Date: Thu, 7 Aug 2008 14:57:45 -0500

Henrik Nordstrom wrote:
> > Is there a need to express the client's expectation that 
> > the "Content-Location" URL will only have a single entity
> > associated with it? Or is a client expected to follow
> > "Content-Location"s for a  number of times?
> 
> It's a protocol expectation as well, very visible in the 
> cache model, so yes if people really think this can be 
> misunderstood then yes it should be clarified that the 
> Content-Location URI SHOULD NOT be a negotiated resource.
> 

Because the cache doesn't dereference the resource identified by the
Content-Location, it doesn't really matter if that resource is negotiated or
not.

To optimize the performance of caches, there are really two things you need
to do: (1) Multiple variants of a resource SHOULD NOT have the same
Content-Location (to prevent unnecessary invalidations), and (2) each entity
(representation) of each variant of a resource SHOULD have the same
Content-Location (to cause invalidations to happen as soon as possible).

Regards,
Brian

---

From: "Brian Smith" <[email-masked]>
Date: Sun, 10 Aug 2008 18:01:27 -0500

Henrik Nordstrom wrote:
> Brian Smith wrote:
> > 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?

The Base-URI part is the main problem. Even if that is overcome, the
security implications are another major problem.

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

Is it RFC 2295 (http://tools.ietf.org/html/rfc2295)?

In my proposed rewrite of the Content-Location definition, I wrote 'Previous
versions of this specification recommended the use of Content-Location to
identify the individual "variants" of a resource. Applications MAY continue
to do so, but the details of this usage are undefined by this specification
(just as they were left undefined in previous versions).' I wrote it that
way for two reasons:

(1) The current proposal for i109 loses the distinction between variants and
entities, but the RFC 2616 definition of Content-Location needs to have that
distinction in order to make sense (because Content-Location identifies a
variant, not an entity). My use of quotes on "variants" is intended to
indicate that the term doesn't have a useful definition (in HTTPbis or RFC
2616).

(2) Like you said, RFC 2616 is unclear about the content model. The
impression I got is that HTTPbis is going to leave the content model
undefined (up to the application) as in RFC 2616. From that, it follows that
any meaning of Content-Location that relies on the content model is going to
be undefined, and so any usage of Content-Location beyond defining the base
URI is also undefined. My statement "but the details of this usage are
undefined..." is just makes that clear in the specification. If HTTPbis is
going to define the content model then the last paragraph of my proposal
would need to be rewritten; in that case, it would be better for defer any
changes to the definition of Content-Location until after the content model
work is done.

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

I agree. But, if there is a content model that all applications are supposed
to follow then the specification should define that model. If there is no
agreed-upon definition of what "accessible at that location" means then
effectively it is meaningless; if there is an agreed-upon definition of
"accessible at that location" then why shouldn't that definition be part of
the specification? 

> The Content-Location text is only a little muddled because of 
> potential security implications if used wrongly ...

The security problem is a big deal.

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

In general, you cannot transition from a GET on one request-URI directly to
a conditional PUT on another URI, regardless of Content-Location, because
you cannot use the ETag from the GET response in the If-Match header of the
PUT (well, you can, but doing so is meaningless). This is stated pretty
clearly in section 3.11 of RFC 2616: "The use of the same entity tag value
in conjunction with entities obtained by requests on different URIs does not
imply the equivalence of those entities." Instead, you have to do a GET on
the Content-Location URI to get the ETag (you cannot use HEAD), and then do
the conditional PUT using the ETag from the second GET. And, besides that,
the security issues get in the way.

- Brian