Re: Prefer Draft Feedback

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 :-)

Received on Monday, 12 December 2011 21:16:44 UTC