- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 6 May 2009 20:47:48 +1000
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
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/
Received on Wednesday, 6 May 2009 10:48:35 UTC