On 2011-12-08 18:56, James Snell wrote:
> Ok, a new draft has been published.
>
> http://www.ietf.org/id/draft-snell-http-prefer-07.txt
>
> After discussing caching issues with Mark in detail, I've made a
> number of important changes to the draft... specifically, it is
> important to point out that Prefer was always intended to be a
> behavior-negotiation mechanism, not content-negotiation. While the
> application of a behavioral preference could potentially impact the
> construction of a response, implementations should avoid utilizing
> preferences in a way that causes a variance in the caching of a
> response. For that reason, I added a new short section detailing cache
> considerations and removed the detail preference. Basically, if you're
> using Prefer for content-negotiation, you're likely doing it wrong.
Not convinced. Where's the difference? If the response without "Prefer"
would have been cacheable, and the presence of the Prefer header field
changes the response I receive, how is that *not* content negotiation?
> Also, per the conversation around return-status, return-representation
> and Preference-Applied, I have removed the return-status and pulled
> Preference-Applied back out. The logic is straightforward... if the
> response cannot be unambiguously determined to be a representation
> response based on a comparison of the effective request URI,
> content-location and, in some cases, the Location header (e.g. for 201
> Created responses), then the client must inspect the content to
> determine the nature of the response regardless of which return-*
> preference was used. Return-status, then, provides no additional value
> and the need for Preference-Applied disappears. If, at some point in
> the future the need for Preference-Applied arises, it can be looked at
> again.
I think this works, but let me try an example to make sure.
Request:
PUT /foo HTTP/1.1
Host: example.com
Prefer: return-representation
Content-Type: text/plain
Hello
Response (1):
HTTP/1.1 200 OK
ETag: "1"
Content-Type: text/plain
/foo updated
or (2)
HTTP/1.1 200 OK
ETag: "1"
Content-Type: text/plain
Content-Location: /foo
Hello
In (1), the response is a status message, in (2) it's the new
representation that I'd also get if I did an immediate GET (and if there
was no in-between modification).
Or with POST:
PUT /container HTTP/1.1
Host: example.com
Slug: bar
Prefer: return-representation
Content-Type: text/plain
Hello
Response (1):
HTTP/1.1 201 Created
ETag: "1"
Content-Type: text/plain
Location: /container/bar
/container/bar created
or (2):
HTTP/1.1 201 Created
ETag: "1"
Content-Type: text/plain
Location: /container/bar
Content-Location: /container/bar
Hello
I think this is going to work.
Best regards, Julian
PS: and notice the beauty of the new ABNF :-)