- From: Mark Baker <distobj@acm.org>
- Date: Fri, 3 Aug 2007 08:44:02 -0400
- To: "Julian Reschke" <julian.reschke@gmx.de>
- Cc: "James M Snell" <jasnell@gmail.com>, "HTTP Working Group" <ietf-http-wg@w3.org>
On 8/3/07, Julian Reschke <julian.reschke@gmx.de> wrote: > > 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. +1 > > 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. Why would a default be needed? > > And then, this probably should go into a separate spec :-). > > Best regards, > > Julian > > Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration strategies http://www.coactus.com
Received on Friday, 3 August 2007 12:44:06 UTC