RE: i107

Mark Nottingham wrote:
> Julian and I were just discussing this (alas, not yet over a 
> Guinness).
> 
> I think the right thing to do here is to describe both 
> variant selection (p3, section 5.1, p6, 16.5) and validator 
> comparison (p4 section 5) in terms of set theory (at least 
> informally), so that the set of representations available for 
> a given request is the intersection of those selected by 
> negotiation and those requested conditionally.
> 
> Make sense?

No, because content negotiation only effects the form of the response
entity, which isn't even a representation of the resource for most kinds of
request. In particular, you cannot use Accept-* headers to narrow the scope
of a PUT/POST/DELETE request to change only particular variants of the
resource, and the server continue to be free to ignore any or all request
header fields (Accept-* in particular) unless RFC 2616 specifically requires
them to not be ignored (e.g. If-* headers, sometimes Content-* headers).

A long time ago I listed some simple examples of how conditional requests
and content negotiation must interact for the most common case we have
today, namely Vary: Accept-Encoding. See
http://article.gmane.org/gmane.ietf.http-wg/795. I am really interested in
getting feedback from those examples.

Here is another example, where /some-image has two representations:
image/png (ETag: "png-1") and image/gif ("gif-1"):

PUT /some-image HTTP/1.1
Content-Type: image/png
If-Match: "gif-1"
Accept: text/html

The client downloaded the GIF variant previously but is uploading a PNG. As
far as content-negotiation is concerned, its only preference is that the
status message in the response entity should be in HTML if possible; the
Accept header isn't saying anything about the representations of the
resource. The only way the server can reasonable handle this request is by
considering the ETags of all representations of the resource when processing
the If-Match header field.

Regards,
Brian

Received on Monday, 28 July 2008 15:41:20 UTC