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

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

>
>> => 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 
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.

Cheers,


Bob

Received on Wednesday, 5 January 2011 14:21:05 UTC