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

From: Julian Reschke <[email-masked]>
Date: Fri, 11 Sep 2009 13:44:47 +0200

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

---

From: Julian Reschke <[email-masked]>
Date: Fri, 11 Sep 2009 14:40:10 +0200

> request-target and the Host header."

I think that definition should go into either Part 1, Section 4.1.2 
("request-target") or Section 4.2 ("The Resource Identified by a Request").

request-target allows 4 different formats:

   request-target = "*"
                  / absolute-URI
                  / ( path-absolute [ "?" query ] )
                  / authority

As far as I can tell, Request-URI only needs to be defined for the 2nd 
and 3rd case.

In case #2 it would be the request-target.

In case #3, it would be "http:" + value of host header + request-target.

But then, what about https? Do we need to consider this in this context? 
Or should we potentially not include the scheme, thus just use

   hier-part [ "?" query ]

? (in which case "Request-URI" would be a bad choice of names).

BR, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 16 Sep 2009 10:23:25 +1000

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

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

---

From: Julian Reschke <[email-masked]>
Date: Wed, 16 Sep 2009 14:13:02 +0200

Mark Nottingham wrote:
>>> 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):
>>> 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]).
>>
>>> same as the request-URI (see [ref]), the response is a representation 
>>> of the resource at the request-URI.

I have a reference to the "Request-URI" ticket 
(<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/196>), and submitted 
the change with <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/695>.

BR, Julian