Subject: Re: Clarifying Content-Location (Issue 136)

From: Mark Nottingham <[email-masked]>
Date: Tue, 6 Oct 2009 15:07:17 +1100

When did that happen? We removed its base-setting ability, not cache  
invalidation, IIRC.

On 28/09/2009, at 1:54 PM, Brian Smith wrote:

> Since the use of Content-Location for cache invalidation was recently
> removed

--
Mark Nottingham     http://www.mnot.net/

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 6 Oct 2009 15:12:13 +1100

I don't think a new issue is necessary; IMO it's a stretch to say that  
the 2616 text requires servers to have separate URIs for different  
variants, and certainly that wasn't in 2068 (see issue text).

What we need is a clear proposal for this issue that wraps up  
dicussion to date.

On 28/09/2009, at 5:26 PM, Julian Reschke wrote:

>>
>> Secondly, why SHOULD servers identify every variant with a URL? I  
>> agree that
>> they MAY do so, but why SHOULD? Especially, if a resource varies  
>> only on
>> Content-Encoding, why SHOULD a server provide three URLs for it?  
>> Besides the
>> base URI issue, it reduces cache efficiency if anybody actually  
>> requests the
>> resource through the Content-Location URLs. It also complicates the
>> management of the URL space on the server. Yet, there's no benefit  
>> to be
>> gained from the added costs.
>
> That's a good point, in particular because of Content-Encoding. I  
> propose that we discuss this as a separate issue (Mark, are you ok  
> with opening a separate one for this?)

---

From: "Brian Smith" <[email-masked]>
Date: Mon, 5 Oct 2009 23:56:05 -0500

Mark Nottingham wrote:
> Sent: Monday, October 05, 2009 11:07 PM
> To: Brian Smith
> Cc: 'Julian Reschke'; 'Robert Brewer'; 'HTTP Working Group'
> Subject: Re: Clarifying Content-Location (Issue 136)
> 

http://trac.tools.ietf.org/wg/httpbis/trac/changeset/691

The above change removes cache invalidation based on Content-Location for
GET/HEAD. The part of P6-cache that discussed cache invalidation based on
Content-Location for PUT, POST, and DELETE was retained. That doesn't make
sense to me; it seems like we should either always invalidation based on
Content-Location (for the same host) or we never should. I support "we never
should" as it makes it easier to get rid of Content-Location.

Regards,
Brian

---

From: "Brian Smith" <[email-masked]>
Date: Mon, 5 Oct 2009 23:58:43 -0500

> variants, and certainly that wasn't in 2068 (see issue text).

I don't get what you mean. Are you saying it is OK to use the same
Content-Location for multiple variants of the same resource? If so, then
what is the point of Content-Location? And, in particular, what is the point
of saying that servers SHOULD return Content-Location when there are
multiple variants, if the Content-Location of those variants could all be
the same as the Request-URI?

- Brian

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 6 Oct 2009 16:17:32 +1100

> should" as it makes it easier to get rid of Content-Location.

Yes, but PUT/POST/DELETE have side effects, and so invalidation makes  
sense in this case.

The text removed in changeset 691 was very specific to a situation  
where C-L matched the request URI and the ETag and Date said it was  
different; it's a very different thing than the invalidation specified  
for methods with side effects.

---

From: "Brian Smith" <[email-masked]>
Date: Tue, 6 Oct 2009 00:26:10 -0500

> for methods with side effects.

No, here is what it said:

    If a cache receives a successful response whose
    Content-Location field matches that of an existing stored
    response for the same Request-URI, whose entity-tag
    differs from that of the existing stored response, and
    whose Date is more recent than that of the existing response,
    the existing response SHOULD NOT be returned in response to
    future requests and SHOULD be deleted from the cache.

In other words:

    If a cache receives a successful response whose
    Content-Location field matches the Content-Location field
    Of an existing stored response for the same request-URI, ...

In particular, note that the cache doesn't compare a Content-Location to a
Request-URI.

Regards,
Brian

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 6 Oct 2009 16:26:30 +1100

I'm saying that I agree with dropping:

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

which is proposed in the issue text.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 6 Oct 2009 16:30:31 +1100

Yep, but it's still fundamentally different, and C-L is still used in  
cache invalidation.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 5 Oct 2009 22:31:25 -0700

> the same as the Request-URI?

Content-Location is for identifying the resource for which the
message payload is a representation.  It does not exist for the
sake of caching.  It will not go away even if caching no longer
mentions it, the spec no longer refers to variants, and the
requirements associated with variants are removed.

Cache invalidation after a successful PUT, POST, or DELETE is
a simple optimization.  It is used in practice for the request URI.
I don't know if it is used in practice for a Content-Location that
does not match the request URI.  Maybe we should check that.
IIRC, that was a late addition to HTTP/1.1.

The base-setting effect was for MIME, MHTML, and message archival.
The only thing we can change is that it does not apply for HTTP.

So, please, if you have specific changes to the document, then
be specific about which sentences need to be removed or fixed.
Please stop ranting about removing the field altogether,
since all that does is interfere with seeing what needs to
be changed in the draft.

....Roy

---

From: Julian Reschke <[email-masked]>
Date: Tue, 06 Oct 2009 07:51:10 +0200

> When did that happen? We removed its base-setting ability, not cache 

That would be <http://tools.ietf.org/wg/httpbis/trac/ticket/154>, which 
we haven't done yet.

> invalidation, IIRC.

I think Brian was referring to 
<http://tools.ietf.org/wg/httpbis/trac/ticket/167>; but as far as I 
understand that was specific to 304 responses.

 > ...

BR, Julian

---

From: "Brian Smith" <[email-masked]>
Date: Tue, 6 Oct 2009 01:42:42 -0500

> requirements associated with variants are removed.

I said that Content-Location's only interoperable use (if any) is for cache.
That is true.

> since all that does is interfere with seeing what needs to

What I said was:

     "when it is different than the request resource's URI"
     is unnecessary and wrong.

and:

     At the very least, the specification must not say that
     Servers "SHOULD" use the Content-Location header.

My full proposal is to change remove all the text in section 5.7 of Part 3,
and replace it with the following:

-- snip --
5.7.  Content-Location

    The "Content-Location" entity-header field is used to supply a URI
    for the entity in the message.

      Content-Location   = "Content-Location" ":" OWS
                            Content-Location-v
      Content-Location-v = absolute-URI / partial-URI

    The meaning of the Content-Location header in requests is
    undefined; servers are free to ignore it in those cases.
-- snip --

This would resolve issue #136 and issue #154. It also makes the
specification easier to read by removing all the explanation of how clients
and caches are NOT allowed to interpret Content-Location (caches, in
particular, can only do what they are specifically allowed to do). It also
removes the redundant statement of how relative URI references are resolved
(which is stated in Part 1, section 2.1).

Regards,
Brian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 6 Oct 2009 12:54:00 -0700

> (which is stated in Part 1, section 2.1).

Thanks Brian.  +1 to the proposal.

....Roy

---

From: Julian Reschke <[email-masked]>
Date: Wed, 07 Oct 2009 15:21:51 +0200

> Thanks Brian.  +1 to the proposal.

Hm,

not convinced. First of all, because this changes too many things at 
once for my taste.

Furthermore,

1) Completely dropping an explanation *why* you would want to supply a 
URI seems to be a bit drastic.

2) I agree that it's clear how relative references are resolved, but I 
think mentioning what the base URI is still useful. Otherwise, we could 
have a generic statement somewhere in Part 1 that, unless stated 
otherwise, relative references are always resolved against the 
Request-URI (noting that we still need a definition for that).

3) I *think* the text should reference the new section in Part 2 
(<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-latest.html#identifying.response.associated.with.representation>)

4) Wrt dropping the base setting semantics I'll reply in a separate mail.

BR, Julian

---

From: "Brian Smith" <[email-masked]>
Date: Wed, 7 Oct 2009 21:55:45 -0500

Julian Reschke [mailto:[email-masked]] wrote:
> >>     The "Content-Location" entity-header field is used to 
> >>     supply a URI for the entity in the message.
> >>

> URI seems to be a bit drastic.

Agreed. Addressed below.

> Request-URI (noting that we still need a definition for that).

As I said, this is already specified in Part 1, section 2.1.

> (<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-
> latest.html#identifying.response.associated.with.representation>)

Agreed. Addressed below.

> 4) Wrt dropping the base setting semantics I'll reply in a separate

The resolution to that issue can be added later. New version:

------------------
5.7.  Content-Location

     The "Content-Location" entity-header field is used to 
     supply a URI for the entity in the message.

     Section 6.1 of Part 2 (Message Semantics) describes how
     clients may process the Content-Location header field.
     Section 2.4 Of Part 6 (Caching) describes how caches
     must process the Content-Location header field. The
     meaning of the Content-Location header field in requests
     is undefined; servers MAY ignore it in requests.
------------------

Regards,
Brian