Re: [apps-discuss] Partially fulfilled / draft-nottingham-http-new-status

Alex Rousskov <rousskov@measurement-factory.com> Tue, 06 December 2011 16:44 UTC

Return-Path: <rousskov@measurement-factory.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C02421F8BEF for <apps-discuss@ietfa.amsl.com>; Tue, 6 Dec 2011 08:44:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIdxZ3sJs6y4 for <apps-discuss@ietfa.amsl.com>; Tue, 6 Dec 2011 08:44:46 -0800 (PST)
Received: from measurement-factory.com (measurement-factory.com [209.169.10.130]) by ietfa.amsl.com (Postfix) with ESMTP id B6BEB21F8BDE for <apps-discuss@ietf.org>; Tue, 6 Dec 2011 08:44:46 -0800 (PST)
Received: from [65.102.233.169] (co-gw.measurement-factory.com [65.102.233.169]) (authenticated bits=0) by measurement-factory.com (8.14.3/8.14.3) with ESMTP id pB6GigrU009487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 6 Dec 2011 09:44:43 -0700 (MST) (envelope-from rousskov@measurement-factory.com)
Message-ID: <4EDE4653.4040201@measurement-factory.com>
Date: Tue, 06 Dec 2011 09:44:03 -0700
From: Alex Rousskov <rousskov@measurement-factory.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15
MIME-Version: 1.0
To: Markus Lanthaler <markus.lanthaler@gmx.net>
References: <000e01ccb3c1$4c347cb0$e49d7610$@lanthaler@gmx.net> <003f01ccb3da$6779f4f0$366dded0$@lanthaler@gmx.net>
In-Reply-To: <003f01ccb3da$6779f4f0$366dded0$@lanthaler@gmx.net>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Wed, 07 Dec 2011 08:02:01 -0800
Cc: ietf-http-wg@w3.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] Partially fulfilled / draft-nottingham-http-new-status
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Dec 2011 16:44:47 -0000

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.