Re: EDITS for Section 10.16 (Content-Location)

Larry Masinter:
>
>> |  Under this specification, the response to a request on one URI can
>> |  never create or update information cached for another URI.  For
>> |  security reasons, when storing the response in cache memory, caches
>> |  MUST use the resource URI indicated by the request, and MUST NOT use
>> |  the URI in the Content-Location header field.
>
>This kind of wording really doesn't belong in the HTTP specification.
>We can say what clients, servers and proxies MUST send or MUST NOT
>send, but putting requirements on implementations and implementation
>techniques just doesn't fly. I think this can be rewritten in terms of
>the meaning of the response rather than constraints on the action of
>the cache when getting a response.
>

Your rewrite below looks good to me.  I have added one small
correction.

>> Note that the Content-location information is advisory, and that
>> there is no guarantee that the URI of the Content-location actually
>> corresponds in any to the original request URI. For example, a cache
                     ^way
>> cannot reliably assume that the data returned as a result of the
>> request can be returned from a new request on any URI other than the
>> original request.

Paul Leach writes about this:
|What good is Content-Location then?

It is not that useful in 1.1.  It will be more useful in the future
content negotiation spec.

| Can the client assume that if it
|GETs the content-location URI returned from GETting a URI of a varying
|resource, that it will get that variant? 

The client could assume this when handling new requests on the varying
resource, _but not_ when handling requests for the content-location
URI.  Content-location only expresses equality of responses in the eye
of the author of the varying resource.  The author of the resource
pointed to by the content-location header may not agree that there is
equality of responses.

|If so, then a cache is a
|client.... If not, what good is Content-Location?

Koen.

Received on Wednesday, 1 May 1996 15:44:20 UTC