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

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