- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 06 May 2009 10:21:45 +0200
- To: Mark Nottingham <mnot@mnot.net>
- CC: HTTP Working Group <ietf-http-wg@w3.org>
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