ISSUE CONTENT-LOCATION: Proposed wording

Description of problem:

	http://www.w3.org/Protocols/HTTP/Issues/#CONTENT-LOCATION

Some comments

- I don't want to bind the Content-Location header to negotiated resources
as anything else than an example of its use as it is very common to do
something like

	GET / HTTP/1.1
	Host: some.host
	
	HTTP/1.1 200 OK
	Content-Location: Overview.html
	...

Overview.html may not have been negotiated at all but is still useful to
editors and the like so that they can check that you don't edit both the
"/" and "/Overview.html" resource. If the client wants to DELETE a
document, it may want to use the Content-Location header as the Request-URI
in order to say exactly what resource, it means. 

In other cases, servers may want to publish only one URL even if the
resource is negotiated each time.

In either case, nothing breaks if content-location is not there at all - it
is strictly informational and hence I would use MAY throughout the
description.

- What does Content-Location mean in a PUT or a POST request? Section 13.10
 mentions Content-Location as a response header and not an entity header
which is in conflict with section 7.1, which I guess should go up as an
editorial issue. I can see Content-Location used in PUT to indicate the
base URL for the document, for example in a "save as" scenario. For POST I
don't know what it means but this may be OK to leave open at this point.

Proposed Solution:

Section 13.10

<<<<<
Some HTTP methods may invalidate an entity. This is either the entity
referred to by the Request-URI, or by the Location or Content-Location
response-headers (if present). These methods are:
=====
Some HTTP methods may invalidate an entity. This is either the entity
referred to by the Request-URI, or by the Location or Content-Location
headers (if present). These methods are:
>>>>>

Section 14.15

<<<<<
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.
=====
The Content-Location entity-header field may 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.
>>>>>

Comments?

Henrik
--
Henrik Frystyk Nielsen, <frystyk@w3.org>
World Wide Web Consortium
http://www.w3.org/People/Frystyk

Received on Thursday, 3 July 1997 12:24:42 UTC