issue & resolution: LOCATION-PUT

> I propose to replace:
> 
> 14.14 Content-Location
> 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.
> 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.
>        Content-Location = "Content-Location" ":" 
>                          ( absoluteURI | relativeURI )
> The value of Content-Location also defines the base URL for the entity
> (see section Error! Reference source not found.).
> 
> The Content-Location value is not a replacement for the original requested
> URI; it is only a statement of the location of the resource corresponding
> to this particular entity at the time of the request. Future requests MAY
> use the Content-Location URI if the desire is to identify the source of
> that particular entity. 
> 
> 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. However, the Content-Location can be used to
> differentiate between multiple entities retrieved from a single requested
> resource, as described in section 13.6.
> 
> If the Content-Location is a relative URI, the relative URI is interpreted
> relative to the Request-URI.
> 
> with
> 14.14 Content-Location
> 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.
>        Content-Location = "Content-Location" ":" 
>                          ( absoluteURI | relativeURI )
> The value of Content-Location also defines the base URL for the entity
> (see section Error! Reference source not found.).
> 
> The Content-Location value is not a replacement for the original requested
> URI; it is only a statement of the location of the resource corresponding
> to this particular entity at the time of the request. Future requests MAY
> specify the Content-Location URI as the request-uri if the desire is to
> access that particular entity. 
> 
> 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. However, the Content-Location can be used to
> differentiate between multiple entities retrieved from a single requested
> resource, as described in section 13.6.
> 
> If the Content-Location is a relative URI, the relative URI is interpreted
> relative to the Request-URI.
> 
> The meaning of the Content-Location header in requests is undefined;
> servers are free to ignore it in those cases.
> 
> To save hunting, the changes are from
> 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.
> to
> 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.
> 
> and from
> Future requests MAY use the Content-Location URI if the desire is to
> identify the source of that particular entity. 
> to
> Future requests MAY specify the Content-Location URI as the request-uri if
> the desire is to access that particular entity. 
> 
> and adds
> The meaning of the Content-Location header in PUT or POST requests is
> undefined; servers are free to ignore it in those cases.
> 
> Rationale:
> The first change makes it clear that the response can only have one
> Content-Location URI; the old wording made it sound like there might be
> two -- one of there are multiple entities, and one for the response
> entity.
> 
> The second change clarifies the vague "to identify the source" to
> something operationally meaningful: to access that particular entity.
> 
> The third change makes it clear that expecting Content-Location to do
> anything on PUT or POST is hopeless.
> 
> Paul
>

Received on Tuesday, 10 March 1998 18:08:48 UTC