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

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 UTC