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

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:16:39 UTC