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

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

Received on Wednesday, 6 May 2009 08:22:37 UTC