W3C home > Mailing lists > Public > www-tag@w3.org > January 2011

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 05 Jan 2011 15:38:42 +0100
Message-ID: <4D248272.6020106@gmx.de>
To: Bob Ferris <zazi@elbklang.net>
CC: www-tag@w3.org
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.

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

Best regards, Julian

PS: you may want to come over to the HTTPBis WG's mailing list for 
further discussion of details like these...
Received on Wednesday, 5 January 2011 15:00:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:29 GMT