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

Am 05.01.2011 15:38, schrieb Julian Reschke:
> On 05.01.2011 15:14, Bob Ferris wrote:
>> Am 05.01.2011 14:50, schrieb Julian Reschke:
>>> On 05.01.2011 11:53, Bob Ferris wrote:
>>>> Hello everybody,
>>>>
>>>> due my recent thoughts in trying to understand the relationship between
>>>> resources, information resources and documents (see [1]), I also had
>>>> the
>>>> chance to have a deeper look into the latest IETF HTTPbis draft.
>>>> Here are my observation:
>>>>
>>>> "An HTTP request representation, when present, is always associated
>>>> with
>>>> an anonymous (i.e., unidentified) resource.
>>>>
>>>> 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.
>>>>
>>>> 1. If the response status code is 200 or 203 and the request method was
>>>> GET, the response payload is a representation of the target resource.
>>>>
>>>> 4. If the response has a Content-Location header field, and that URI is
>>>> not the same as the effective request URI, then the response asserts
>>>> that its payload is a representation of the resource identified by the
>>>> Content-Location URI. However, such an assertion cannot be trusted
>>>> unless it can be verified by other means (not defined by HTTP)." (see
>>>> [2])
>>>>
>>>> => that means i.e. it is not a representation of the requested URI, but
>>>> rather it can be a representation of the description that is identified
>>>> by the Content-Location URI; that means for the 200 response code case:
>>>> the target resource is identified by the Content-Location URI
>>>
>>> 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.

>
>>>> => in general it is the same with fragment Ids, however generally the
>>>> request engines strip down the fragment Id and do the requested with
>>>> that new URI, however the effective request URI is that one with the
>>>
>>> Sorry? The "effectice request URI" is defined in
>>> <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-12.html#effective.request.uri>
>>>
>>>
>>> and by definition does not include a fragment identifier.
>>
>> Yeah, I know what you mean (btw, I searched for quite a while for this
>> definition, but hadn't found it - is it new?). You are pointing to the
>
> Relatively new, yes.
>
>> difference between URI and URIref. However, since resources can also be
>> identified by URIs with fragements, we should consider them as their
>> effective request URIs. From my point of view this would deregulate the
>> differentiated handling of hash and slash URIs in this case.
>
> 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 
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).
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.

Cheers,


Bob


*) that is what is also stated in point 1 of this list, which I would 
say is a bit in contradiction with the points 3 and 4, since a 200 
response can also include a Content-Location and that URI can be 
different from the effective request URI

Received on Wednesday, 5 January 2011 17:32:17 UTC