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

Mark Nottingham <mnot@mnot.net> Wed, 07 December 2011 02:03 UTC

Return-Path: <mnot@mnot.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 C003E21F8B70 for <apps-discuss@ietfa.amsl.com>; Tue, 6 Dec 2011 18:03:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.158
X-Spam-Level:
X-Spam-Status: No, score=-105.158 tagged_above=-999 required=5 tests=[AWL=-2.559, 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 y72SO6InPTLs for <apps-discuss@ietfa.amsl.com>; Tue, 6 Dec 2011 18:03:45 -0800 (PST)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 16AA421F8B6D for <apps-discuss@ietf.org>; Tue, 6 Dec 2011 18:03:44 -0800 (PST)
Received: from mnot-mini.mnot.net (unknown [118.209.121.109]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 95B0C50A5D; Tue, 6 Dec 2011 21:03:37 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset="us-ascii"
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <003f01ccb3da$6779f4f0$366dded0$@lanthaler@gmx.net>
Date: Wed, 07 Dec 2011 13:03:33 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <83DF3CE2-C111-41CA-BA98-BC5BD50BD012@mnot.net>
References: <000e01ccb3c1$4c347cb0$e49d7610$@lanthaler@gmx.net> <003f01ccb3da$6779f4f0$366dded0$@lanthaler@gmx.net>
To: Markus Lanthaler <markus.lanthaler@gmx.net>
X-Mailer: Apple Mail (2.1251.1)
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: Wed, 07 Dec 2011 02:03:45 -0000

Why is it necessary to surface this information in the status code? E.g., will intermediaries or automated software that's not specific to the application at hand be able to use it? 

Regards,


On 06/12/2011, at 4:46 PM, Markus Lanthaler wrote:

> Mark,
> 
> I've considered 202 Accepted but it has a completely different meaning. 202
> is defined as:
> 
>  "The request has been accepted for processing, but the processing has not
>   been completed. The request might or might not eventually be acted
> upon.."
> 
> I proposed to introduce a new status code for requests that have been fully
> processed but could just be fulfilled partially. Thinking more about it I
> came up with another example where this might be very useful.
> 
> Assume we have a Web service. Clients send requests and everything works
> fine -> 200 OK. At a certain point in time the Web service adds new
> optional(!) functionality which is not critical and clients start to use it.
> A simple example could be that clients transmit some additional data. If the
> server gets updated as well and understand all the data, again a 200 OK is
> fine.
> 
> But if a server is not updated to the latest version it might understand
> just parts of the request (the critical part) and simply ignore the other
> parts. To tell the client that it successfully processed the request but
> didn't understand parts of the request he would return a, e.g., 209
> Partially Fulfilled.
> 
> 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.
> 
> 
> --
> Markus Lanthaler
> @markuslanthaler
> 

--
Mark Nottingham   http://www.mnot.net/