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

Alex Rousskov <> Tue, 06 December 2011 16:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3C02421F8BEF for <>; Tue, 6 Dec 2011 08:44:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.599
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WIdxZ3sJs6y4 for <>; Tue, 6 Dec 2011 08:44:46 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B6BEB21F8BDE for <>; Tue, 6 Dec 2011 08:44:46 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (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
Message-ID: <>
Date: Tue, 06 Dec 2011 09:44:03 -0700
From: Alex Rousskov <>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20110922 Thunderbird/3.1.15
MIME-Version: 1.0
To: Markus Lanthaler <>
References: <000e01ccb3c1$4c347cb0$e49d7610$> <003f01ccb3da$6779f4f0$366dded0$>
In-Reply-To: <003f01ccb3da$6779f4f0$366dded0$>
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
Subject: Re: [apps-discuss] Partially fulfilled / draft-nottingham-http-new-status
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.