- From: Alex Rousskov <rousskov@measurement-factory.com>
- Date: Tue, 06 Dec 2011 09:44:03 -0700
- To: Markus Lanthaler <markus.lanthaler@gmx.net>
- CC: ietf-http-wg@w3.org, apps-discuss@ietf.org
On 12/05/2011 10:46 PM, Markus Lanthaler wrote: > It is not unusual that a request can be considered as successful even > if it couldn't be fulfilled completely. ... > I think such a behaviour would be very important in evolving systems. As far > as I know, there are currently only two ways to deal with it: either process > the request and return a 200 OK signalling everything was OK or ignoring the > request and returning a 400 Bad Request. A third way would be to return a 200 OK response with an extension response header or custom body that indicates which parts of the request were not "fully fulfilled". A forth way would be to include extension request headers or custom body pieces indicating client preferences with regard to considering partially fulfilled requests successful. >From HTTP point of view, 200 OK seems like an appropriate response here because the transaction went through and the HTTP server considered it a success. The application-level details of that success can be left to the extension headers or body. A user-agent receiving just a "partially fulfilled" status code is likely to want a lot more information anyway, resulting in the additional requests you wanted to avoid. For example, a purchase order-placing agent would want to know which items were not ordered before deciding whether to revoke the partial order. HTH, Alex.
Received on Tuesday, 6 December 2011 16:45:16 UTC