W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2011

Re: Partially fulfilled / draft-nottingham-http-new-status

From: Alex Rousskov <rousskov@measurement-factory.com>
Date: Tue, 06 Dec 2011 09:44:03 -0700
Message-ID: <4EDE4653.4040201@measurement-factory.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:50 GMT