W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2008

RE: i107

From: Brian Smith <brian@briansmith.org>
Date: Mon, 28 Jul 2008 10:25:04 -0500
To: "'Mark Nottingham'" <mnot@mnot.net>, "'Henrik Nordstrom'" <henrik@henriknordstrom.net>
Cc: "'HTTP Working Group'" <ietf-http-wg@w3.org>
Message-ID: <4FE2A68208144A94A9388EC7EEC0BE36@T60>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:53 GMT