#110: how to determine what entity a response carries

[mnot]

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

[Julian Reschke]

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

Yes.

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

That seems to be in conflict with RFC 4918, Section 5.2:

"There is a standing convention that when a collection is referred to by
its name without a trailing slash, the server MAY handle the request as
if the trailing slash were present. In this case, it SHOULD return a
Content-Location header in the response, pointing to the URL ending with
the "/"." --
<http://greenbytes.de/tech/webdav/rfc4918.html#rfc.section.5.2.p.8>

...which really is about PROPFIND in practice. So would we consider this
a bug in the WebDAV spec?

> 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 entity body sent with a 404? No.

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

Issue 22 is about cases like where a PUT response carries an ETag, but
no response entity (no Content-Location header). That case would fall
under 5), so resolving issue 110 as proposed wouldn't really help with
issue 22, right? (That's ok, just trying to understand the relation
between these two)

BR, Julian

[mnot]

On 06/05/2009, at 6:21 PM, Julian Reschke wrote:

> 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).
>
> Yes.
>
>> 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).
>
> That seems to be in conflict with RFC 4918, Section 5.2:
>
> "There is a standing convention that when a collection is referred  
> to by its name without a trailing slash, the server MAY handle the  
> request as if the trailing slash were present. In this case, it  
> SHOULD return a Content-Location header in the response, pointing to  
> the URL ending with the "/"." -- <http://greenbytes.de/tech/webdav/rfc4918.html#rfc.section.5.2.p.8 
> >
>
> ...which really is about PROPFIND in practice. So would we consider  
> this a bug in the WebDAV spec?

I'm inclined to squint at WebDAV and see it as an application layered  
on top of HTTP, and this is just application-specific semantics on top  
of HTTP's...


>> 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 entity body sent with a 404? No.

Yeah. The interesting thing for me is that HTTP caching is defined in  
terms of responses, not representations, and it's perfectly valid to  
cache a 404 (or many other responses, as we've seen). I think the  
outcome here is that we need to be very crisp about the terminology  
here, so as not to confuse.

>> 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>.
>> ...
>
> Issue 22 is about cases like where a PUT response carries an ETag,  
> but no response entity (no Content-Location header). That case would  
> fall under 5), so resolving issue 110 as proposed wouldn't really  
> help with issue 22, right? (That's ok, just trying to understand the  
> relation between these two)

Ah, yes. To help #22, there'd need to be a new rule, something like

n) If the response status is in [200, 201, others?] and the request  
method is PUT, the response is a representation of the requested  
variant [ see #69 ].

I dislike all of these special cases, but I don't see any way around  
it. Still not sure how / if this should surface in the spec.


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

[Brian Smith-19]

Mark Nottingham wrote:

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

This kind of rule is only helpful if the application is going to save the
response in a cache,  avoiding a GET to the request-URI. But, another part
of the spec. already says we cannot add a response to a cache based on the
Content-Location header; we can only use Content-Location for
*invalidation*.

> The bigger question, though, is how this affects the spec.

Anybody that needs to make these kinds of inferences can infer the rules
from the spec as you did. Adding some algorithm for this to the spec. would
be redundant at best (if the algorithm was completely consistent with the
rest of the spec) and contradictory/misleading at worst.

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

Issues like #22 will be easy to resolve once it is acknowledged that "the
response that would be returned upon a GET" only makes sense for HEAD and
not PUT/POST/DELETE/etc. due to content negotiation.

Regards,
Brian

[mnot]

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/

[Julian Reschke]

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

[Julian Reschke]

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

[mnot]

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/

[Julian Reschke]

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

[mnot]

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/

[Julian Reschke]

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

[mnot]

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:

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

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