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

Alex Rousskov <rousskov@measurement-factory.com> Wed, 07 December 2011 05:09 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 C248121F8560 for <apps-discuss@ietfa.amsl.com>; Tue, 6 Dec 2011 21:09:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.266
X-Spam-Level:
X-Spam-Status: No, score=-106.266 tagged_above=-999 required=5 tests=[AWL=-3.667, 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 QbfBZ--LM-nD for <apps-discuss@ietfa.amsl.com>; Tue, 6 Dec 2011 21:09:08 -0800 (PST)
Received: from measurement-factory.com (measurement-factory.com [209.169.10.130]) by ietfa.amsl.com (Postfix) with ESMTP id 3408521F8558 for <apps-discuss@ietf.org>; Tue, 6 Dec 2011 21:09:08 -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 pB758sBj080476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 6 Dec 2011 22:08:59 -0700 (MST) (envelope-from rousskov@measurement-factory.com)
Message-ID: <4EDEF4BD.10108@measurement-factory.com>
Date: Tue, 06 Dec 2011 22:08:13 -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: <4EDE4653.4040201@measurement-factory.com> <CAKTR038wj4cJsAyyULF+Cn+c9VAS_pkbJ+m2i602mgBm6x2sog@mail.gmail.com> <006601ccb488$1ea9faf0$5bfdf0d0$@lanthaler@gmx.net>
In-Reply-To: <006601ccb488$1ea9faf0$5bfdf0d0$@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: Wed, 07 Dec 2011 05:09:08 -0000

On 12/06/2011 07:29 PM, Markus Lanthaler wrote:
> On Tue, Dec 6, 2011 at 4:44 PM, Alex Rousskov wrote:
> 
>> 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.
> 
> What do you mean by extension response/request headers? Are you talking
> about RFC 2774 [1] or just some proprietary (X-)headers?
> 
> [1] http://www.ietf.org/rfc/rfc2774.txt

Any message extension headers as defined by RFC 2616 Section 7.1.
Whether they are [going to be] documented by some RFC, have an X-
prefix, and/or remain application-specific is not important for this
discussion, IMHO.

My point is that there are existing HTTP mechanisms that can be used to
report to the client that parts of a successful HTTP transaction were
not entirely successful from the application point of view (and that
those rich mechanisms appear to be more suitable than a single new
status code).

Compared to using extension headers and/or custom response bodies,
adding a new standard response code is a more rigid/limited solution and
its support is going to be more expensive for HTTP agents that do not
need to know about any of this (e.g. proxies already know how to ignore
extension headers or body content, but new status codes often require
explicit care).

On the other hand, since I am not writing applications that deal with
partially fulfilled requests, I could be easily missing something that
prompts folks to suggest a new response status code instead.


Cheers,

Alex.