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

From: Mark Nottingham <[email-masked]>
Date: Wed, 6 May 2009 17:00:54 +1000

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

---

From: Julian Reschke <[email-masked]>
Date: Wed, 06 May 2009 10:21:45 +0200

Mark Nottingham wrote:
> AFAICT the process you have to go through to figure this out is roughly 
> (first match wins);
> 

Yes.

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

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

> ...

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

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 6 May 2009 20:47:48 +1000

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

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

>> There are some open questions here -- e.g., is a 404 a  
>> representation of that resource? (maybe).
>

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.

---

From: "Brian Smith" <[email-masked]>
Date: Wed, 6 May 2009 09:53:27 -0500

Mark Nottingham wrote:

>    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