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 14:50:37 +0100
Message-ID: <4D24772D.4050400@gmx.de>
To: Bob Ferris <zazi@elbklang.net>
CC: www-tag@w3.org
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.

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

 > ...

Best regards, Julian
Received on Wednesday, 5 January 2011 13:52:18 GMT

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