W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1998

issue & resolution: LOCATION-PUT

From: Paul Leach <paulle@microsoft.com>
Date: Tue, 10 Mar 1998 17:42:47 -0800
Message-Id: <5CEA8663F24DD111A96100805FFE6587031E3BC2@red-msg-51.dns.microsoft.com>
To: 'http-wg' <http-wg@cuckoo.hpl.hp.com>
> 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 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:13 EDT