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

From: Mark Nottingham <[email-masked]>
Date: Wed, 5 Aug 2009 14:37:01 -0700

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.

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

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.

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

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

I think these are both new issues, BTW.

The implied resolution to #22 <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/22 
 > would be, roughly:

p2 8.2.2 201 Created:

old:
"A 201 response MAY contain an ETag response header field indicating  
the current value of the entity tag for the requested variant just  
created, see Section 6.1 of [Part4]."

new:
"A 201 response MAY use a Content-Location header to indicate that it  
is a representation of the newly created resource's state; see [ref to  
new section defined above]."

We'd also need to change the definition of response header-fields;

old:
"These header fields give information about the server and about  
further access to the resource identified by the request- target."

new:
"These header fields give information about the server and about  
further access to the resource associated with the representation."

On 06/05/2009, at 12:00 AM, Mark Nottingham wrote:

>
> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/110>
>
> AFAICT the process you have to go through to figure this out is  
> roughly (first match wins);
>
> 1) If the response status is in [200, 203] and the request method  
> was GET, the response is a representation of the request-URI.
>
> 2) If the response status is in [204, 206, 304] and the request  
> method was in [GET, HEAD], the response is a partial representation  
> of the request-URI (here 'partial' meaning that it may just be  
> entity headers).
>
> 3) If the response has a Content-Location header, and that URI is  
> the same as the request-URI, the response is a representation of the  
> request-URI.
>
> 4) If the response has a Content-Location header, the response  
> asserts that it is a representation of the Content-Location URI (but  
> it may not be).
>
> 5) Otherwise, the response is a representation of an anonymous /  
> unidentified resource.
>
>
> There are some open questions here -- e.g., is a 404 a  
> representation of that resource? (maybe).
>
> The bigger question, though, is how this affects the spec. I think  
> the main impact -- if we can come to agreement, of course -- is on  
> issues like <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/22>.
>
>
> Thoughts?
>
> --
> Mark Nottingham     http://www.mnot.net/
>
>

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