Re: PATCH, Expect, Prefer, etc

James M Snell wrote:
> Ok, the recent conversation around the use of the 200/204 status codes
> in the current PATCH draft has indicated that a couple of new status
> codes and a new request header would likely be helpful. So how about
> something like this:
> 
> ---
> 208 Content Returned

209. (see 
<http://tools.ietf.org/html/draft-ietf-webdav-bind-19#section-12>).

> The request has succeeded.  The information returned with the response
> is equivalent to what would be returned in a subsequent GET on the resource.

This may need to state something about variant selection.

> 418 Preference Failed
> 
> The preference given in a Prefer request-header field was understood by
> could not be met by this server.

I'm not sure this should even be an error condition. Wouldn't it be 
wiser to just let the server execute the operation? It's "preference", 
not "expectation", after all.

> Prefer header
> 
> The Prefer request-header field is used to indicate that particular
> server behaviors are preferred by the client.
> 
>   Prefer = "Prefer" ":" 1#preference
> 
>   preference  = "208-content-returned" |
>                 "204-no-content" |
>                 preference-extension
> 
>   preference-extension = token [ "=" ( token | quoted-string )
>                          *preference-params ]
> 
>   preference-params = ";" token [ "=" ( token | quoted-string ) ]
> 
> A server that does not understand or is unable to comply with any of the
> preference values in the Prefer field of a request MUST ignore those
> values.  The server MAY response with a 418 (Preference Failed) status

s/response/respond/

> ...
> The Prefer header is defined to be generally identical to Expect with
> the difference being that Prefer MUST be ignored if it is not
> understood.  A server can choose not to fulfill a preference and
> communicate that choice to the client using 418, but proxies are
> required to forward them on.
> 
> A proxy can choose to fulfill a preference if it is capable.  For
> instance, a proxy that receives a 200 or 209 response to a request that
> contains Prefer: 204-no-content can choose to return 204 No Content to
> the client rather than the complete original response.  If the request
> contains 209-content-returned and the server responds with 200 or 204
> (or whatever), then it obviously will not be capable of fulfilling the
> preference and must ignore it.
> 
> Thoughts?

Also, I'd clarify that the default response for a successful PATCH would 
be 204, not 208.

And then, this probably should go into a separate spec :-).

Best regards,

Julian

Received on Friday, 3 August 2007 07:35:30 UTC