Re: #110: how to determine what entity a response carries

Mark Nottingham wrote:
> This was discussed in the Stockholm meeting; people agreed with this 
> general approach.
> 
> Revised proposal:
> 
> ---8<---
> 
> * Identifying the Resource Associated with a Representation
> 
> It is sometimes necessary to determine the identify of the resource 
> associated with a representation.

s/identify/identity/

> 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 resource 
> located at the request-URI. However, this is not always the case. To 
> determine the URI of the resource a response is associated with, the 
> following rules are used (first match winning):
> 
> 1) If the response status code is 200 or 203 and the request method was 
> GET, the response is a representation of the resource at the request-URI.
> 
> 2) If the response status is 204, 206, or 304 and the request method was 
> GET or HEAD, the response is a partial representation of the resource at 
> the request-URI (see [ref to section on combining partial responses in 
> p6]).

Section 2.7 of [Part6] (I think)

> 3) If the response has a Content-Location header, and that URI is the 
> same as the request-URI (see [ref]), the response is a representation of 
> the resource at the request-URI.
> 
> 4) If the response has a Content-Location header, and that URI is not 
> the same as the request-URI, the response asserts that it is a 
> representation of the resource at the Content-Location URI (but it may 
> not be).
> 
> 5) Otherwise, the response is a representation of an anonymous (i.e., 
> unidentified) resource.
> 
> --->8---
> 
> Suggested placement: a new section, either p2 6.1 or p3 3.3.

I think P2 6.1 makes a lot of sense, proposed (partial, see below) 
patch: 
<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/110/110.diff>.

> Note that 'request-URI' is used here; however, we need to come up with a 
> term to denote "the URI that can be inferred from examining the 
> request-target and the Host header."

I think the term "Request-URI" makes a lot of sense, because it already 
is in use for that purpose (although in RFC2616 it didn't mean exactly 
that).

The definition will need to go into P1, Section 4. Mark, are you going 
to open a ticket for that one?

> Also, the comparison function is going to have to be defined somewhere, 
> because we already need to compare URIs for things like cache invalidation.

Any reason why we can't use P1, Section 2.6.3? 
(<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-latest.html#uri.comparison>)

> I think these are both new issues, BTW.
> ...

BR, Julian

Received on Friday, 11 September 2009 11:52:25 UTC