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

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.

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

> 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" :-)

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

Best regards, Julian

Received on Wednesday, 5 January 2011 17:50:08 UTC