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

On 11/09/2009, at 9:44 PM, Julian Reschke wrote:

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

Makes sense.

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

Now <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/196>.

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

Think so, yes.

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


--
Mark Nottingham     http://www.mnot.net/

Received on Wednesday, 16 September 2009 00:24:05 UTC