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

From: Mark Nottingham <[email-masked]>
Date: Tue, 6 Oct 2009 15:03:31 +1100

Closing #110; we can tweak the language editorially as necessary later  
(e.g., when the representation/entity language is rationalised).

On 16/09/2009, at 10:13 PM, Julian Reschke wrote:

> Mark Nottingham wrote:
>> 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 
>>> >.
>> ...
>
> 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
>

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

---

From: Julian Reschke <[email-masked]>
Date: Thu, 08 Oct 2009 16:52:34 +0200

Mark Nottingham wrote:
> ...
>>> 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 noticed that Strict Transport Security (STS) 
(<http://lists.w3.org/Archives/Public/www-archive/2009Sep/att-0051/draft-hodges-strict-transport-sec-05.plain.html>) 
calls this "Effective Request URI", which I think makes a lot of sense.

BR, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 15 Oct 2009 15:07:23 +1100

Flipping this to editorial; I don't think there's a design aspect to  
this one (it's just specifying something already present more clearly).

On 09/10/2009, at 1:52 AM, Julian Reschke wrote:

>>>> with a term to denote "the URI that can be inferred from  
>>>> examining the request-target and the Host header."
>>>
>>> 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?
>>>> 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 noticed that Strict Transport Security (STS) (<http://lists.w3.org/Archives/Public/www-archive/2009Sep/att-0051/draft-hodges-strict-transport-sec-05.plain.html 
> >) calls this "Effective Request URI", which I think makes a lot of  
> sense.
>
> BR, Julian
>