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

Sam Johnston <samj@samj.net> Tue, 06 December 2011 19:09 UTC

Return-Path: <samj@samj.net>
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 1BD4521F8BBA for <apps-discuss@ietfa.amsl.com>; Tue, 6 Dec 2011 11:09:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.976
X-Spam-Level:
X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 LB01oaKhN11R for <apps-discuss@ietfa.amsl.com>; Tue, 6 Dec 2011 11:09:04 -0800 (PST)
Received: from eu1sys200aog119.obsmtp.com (eu1sys200aog119.obsmtp.com [207.126.144.147]) by ietfa.amsl.com (Postfix) with ESMTP id C746821F8B71 for <apps-discuss@ietf.org>; Tue, 6 Dec 2011 11:09:02 -0800 (PST)
Received: from mail-gx0-f182.google.com ([209.85.161.182]) (using TLSv1) by eu1sys200aob119.postini.com ([207.126.147.11]) with SMTP ID DSNKTt5oPo9a4lSODGHpQt8kxX2P0tNeiAIW@postini.com; Tue, 06 Dec 2011 19:09:03 UTC
Received: by mail-gx0-f182.google.com with SMTP id p1so6085012ggn.27 for <apps-discuss@ietf.org>; Tue, 06 Dec 2011 11:08:46 -0800 (PST)
Received: by 10.236.189.104 with SMTP id b68mr6575433yhn.21.1323198526290; Tue, 06 Dec 2011 11:08:46 -0800 (PST)
MIME-Version: 1.0
Received: by 10.236.105.233 with HTTP; Tue, 6 Dec 2011 11:08:25 -0800 (PST)
In-Reply-To: <4EDE4653.4040201@measurement-factory.com>
References: <4EDE4653.4040201@measurement-factory.com>
From: Sam Johnston <samj@samj.net>
Date: Tue, 6 Dec 2011 19:08:25 +0000
Message-ID: <CAKTR038wj4cJsAyyULF+Cn+c9VAS_pkbJ+m2i602mgBm6x2sog@mail.gmail.com>
To: Alex Rousskov <rousskov@measurement-factory.com>
Content-Type: multipart/alternative; boundary=20cf303f6bae20795304b3712a9d
X-Mailman-Approved-At: Wed, 07 Dec 2011 08:02:01 -0800
Cc: apps-discuss@ietf.org, ietf-http-wg@w3.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 19:09:05 -0000

On Tue, Dec 6, 2011 at 4:44 PM, Alex Rousskov <
rousskov@measurement-factory.com> wrote:

> 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.
>

Agreed — if you're going to have to define a custom format anyway (as you
are in almost every case) then you're probably better off just using
existing codes.

"202 Accepted" applies to any state up to (but not including) completion,
so it's not really appropriate for synchronous requests, while "200 OK"
specifically allows for "an entity describing or containing the result of
the action".

That said, as I'm busy applying HTTP (as it was intended rather than with
envelope layers) to cloud standards I find myself regularly wanting to give
status updates — as x of y units, %, etc. — and it could be useful to have
a header that carried this information in a sensible/standard format. A
marked up Link: to a [text/uri-]list of components could be interesting too.

Sam