Re: Understanding 'Content-Location' header in the IETF HTTPbis draft

Hi Bob,

Here's the way I look at this, given the URI 
http://example.org/some#thing, and given that we know we can dereference 
it to find out more about it, then, we can simply say that we are 
looking for:

  "#thing", as described by "http://example.org/some" **

And thus "http://example.org/some" identifies a resource, the 
representation of which is a description (in whatever negotiated format 
that may be), and that description will (hopefully) contain statements 
made about "#thing", that is, include a description of "#thing", the 
secondary resource.

If all goes well, and you get a 200 response, then regardless of having 
any Content-Location header, you have retrieved a representation of the 
requested resource, and the URI, the effective request uri, corresponds 
to the resource you requested ("http://example.org/some"). If you also 
get a Content-Location header with a URI which is different to the 
effective request uri, then that URI is a more specific URI for the 
particular (negotiated) representation you retrieved.

If you receive any response code other than 200 in reply to a GET, then 
the message-body, and it's related headers (like Content-Location) are 
not a representation of the requested resource, but rather they are a 
message describing what went wrong, what options you have, or what you 
can do next.

There may an error or two in the above, but that's certainly my general 
understanding of things.

Best,

Nathan

Bob Ferris wrote:
> Am 05.01.2011 18:49, schrieb Julian Reschke:
>> On 05.01.2011 18:29, Bob Ferris wrote:
>>> ...
>>>>>> Hm, no.
>>>>>>
>>>>>> You skipped an important sentence:
>>>>>>
>>>>>>> In the common case, an HTTP response is a representation of the
>>>>>>> target resource (see Section 4.3 of [Part1]). However, this is not
>>>>>>> always the case. To determine the URI of the resource a response is
>>>>>>> associated with, the following rules are used (with the first
>>>>>>> applicable one being selected):
>>>>>>
>>>>>> So point 4 doesn't apply to a 200 response to GET.
>>>>>
>>>>> I don't understand this. I thought that it is quite normal that a 200
>>>>> response also includes an Content-Location header
>>>>
>>>> Yes, but the text you cited from
>>>> <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-12.html#rfc.section.6.1> 
>>>>
>>>>
>>>>
>>>> isn't about that case.
>>>>
>>>> That is, the "resource associated with a representation" in a GET->200
>>>> response is the one identified by the effective request URI.
>>>
>>> From my understanding only the omitted point three:
>>>
>>> "3. If the response has a Content-Location header field, and that URI is
>>> the same as the effective request URI, the response payload is a
>>> representation of the target resource."
>>>
>>> would allow to conclude this.
>>
>> "To determine the URI of the resource a response is associated with, the
>> following rules are used (with the first applicable one being selected):"
>>
>> So in this case you don't get to point 3.
> 
> OK. Got it. However, I don't like it. I really prefer the treating of 
> the Content-Location header value as described in the points 3 and 4.
>>
>>  > ...
>>>> We have introduced the term for something very specific in the HTTP
>>>> protocol, and that simply doesn't *have*' a fragment id.
>>>
>>> To understand this correct, an 'effective request URI' and from your
>>> definitions then also a 'target resource URI' doesn't have a fragment
>>> id? So how would you call then a URI I like to request that includes a
>>
>> Yes. There is no fragment ID in HTTP requests.
> 
> So I cannot use it for resource identification purpose, since I need a 
> consistent method for all URIs (incl. these ones with fragment ids). 
> This was also a finding (at least for myself) in my mentioned blog post.
> 
>>
>>> fragment id? From my understanding I use therefore the general term
>>> Resource URI (which identifies an Resource, which was the target
>>> resource from understanding before).
>>
>> Just call it "URI" :-)
> 
> Yes, for differentiation purpose, I thought it might be better to have a 
> specific name for the URI of the 'requested resource'.
> 
>>
>>> Furthermore, then a 200 response code would never tell me something
>>> about a resource that has a URI with a fragment id, but it can tell me
>>> something about a resource with a URI without fragment id, if this URI
>>> is equal to the Content-Location URI (and only then), namely* that the
>>> response payload is a representation of the target resource.
>>
>> Again, there are no fragment IDs in HTTP requests. HTTP doesn't care.
>>
>> A 200 response to GET carries a representation of the requested
>> resource. Full stop. It may carry a C-L header as well, but that's not
>> what *that* particular paragraph is worried about.
> 
> Yes, but this paragraph was about "Identifying the Resource Associated 
> with a Representation", which can have a URI with a fragment id as well 
> (from my understanding).
> Identification (I see it always more into the direction of naming or 
> denotation) and access are two different tasks. HTTP is then maybe more 
> responsible for the access task, rather then for the identification task.
> I can interpret the following statement from the GET definition [1]
> 
> "The GET method means retrieve whatever information (in the form of a 
> representation) currently corresponds to the target resource."
> 
> also as a Description (that is embodied as a Representation) of the 
> target resource. For that matter, an Information Resource can be mapped 
> to the abstract information, which is then be realized by a concrete 
> Description (the model level based on a language - natural or formal - 
> that is especially important for the semantics) e.g., a Semantic Graph 
> or a text in a natural language. This concrete Description would be 
> serialized at the end to a Representation e.g., a RDF/N3 formatting of 
> the Semantic Graph or a HTML formatting of the text.
> 
> Cheers,
> 
> 
> Bob
> 
> 
> [1] 
> http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-12.html#GET 
> 
> 
> 
>

Received on Wednesday, 5 January 2011 19:44:55 UTC