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.
- [apps-discuss] Partially fulfilled / draft-nottin… Markus Lanthaler
- Re: [apps-discuss] Partially fulfilled / draft-no… Markus Lanthaler
- Re: [apps-discuss] Partially fulfilled / draft-no… Mark Nottingham
- Re: [apps-discuss] Partially fulfilled / draft-no… Markus Lanthaler
- Re: [apps-discuss] Partially fulfilled / draft-no… Markus Lanthaler
- Re: [apps-discuss] Partially fulfilled / draft-no… Peter Saint-Andre
- Re: [apps-discuss] Partially fulfilled / draft-no… Alex Rousskov
- Re: [apps-discuss] Partially fulfilled / draft-no… Sam Johnston
- Re: [apps-discuss] Partially fulfilled / draft-no… Alex Rousskov
- Re: [apps-discuss] Partially fulfilled / draft-no… Mark Nottingham