HTTP status code for "response too large"

Andreas Maier <> Wed, 18 April 2012 11:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 073C421F858B for <>; Wed, 18 Apr 2012 04:44:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.11
X-Spam-Status: No, score=-9.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WEbTgoXPjDjY for <>; Wed, 18 Apr 2012 04:44:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2C5AB21F8531 for <>; Wed, 18 Apr 2012 04:44:20 -0700 (PDT)
Received: from lists by with local (Exim 4.69) (envelope-from <>) id 1SKTHJ-0006ii-9L for; Wed, 18 Apr 2012 11:42:29 +0000
Received: from ([]) by with esmtp (Exim 4.69) (envelope-from <>) id 1SKTH9-0006hm-AE for; Wed, 18 Apr 2012 11:42:19 +0000
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1SKTGy-0006sf-Eg for; Wed, 18 Apr 2012 11:42:17 +0000
Received: from /spool/local by with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for <> from <>; Wed, 18 Apr 2012 12:41:41 +0100
Received: from ( by ( with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 18 Apr 2012 12:41:39 +0100
Received: from ( []) by (8.13.8/8.13.8/NCO v10.0) with ESMTP id q3IBfcu71826976 for <>; Wed, 18 Apr 2012 12:41:38 +0100
Received: from (loopback []) by (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q3IBfcW0032538 for <>; Wed, 18 Apr 2012 05:41:38 -0600
Received: from ( []) by (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q3IBfcdP032533; Wed, 18 Apr 2012 05:41:38 -0600
X-KeepSent: D186EDCA:AF2D3EBA-852579E4:003EB3DE; type=4; name=$KeepSent
To: Mark Nottingham <>
Cc: IETF HTTP WG <>, Thomas Narten <>
X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009
Message-ID: <>
From: Andreas Maier <>
Date: Wed, 18 Apr 2012 07:41:24 -0400
X-MIMETrack: Serialize by Router on D06ML032/06/M/IBM(Release 8.5.2FP3|July 10, 2011) at 18/04/2012 13:41:32
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
x-cbid: 12041811-3548-0000-0000-000001A731F3
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-1.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01
X-W3C-Scan-Sig: 1SKTGy-0006sf-Eg ee0795b5f28ba48eff87e7b1a54098b8
Subject: HTTP status code for "response too large"
Archived-At: <>
X-Mailing-List: <> archive/latest/13452
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>
Resent-Message-Id: <>
Resent-Date: Wed, 18 Apr 2012 11:42:29 +0000

Hi Mark,
I am working for IBM in the DMTF standards org. We are defining a RESTful
protocol for CIM based directly on HTTP ("CIM-RS"), and we want to be as
truthfully RESTful and HTTP compliant as possible.

We want to support an "expand" query parameter that causes references to
resources in the result to be expanded to the resources that they
reference. One of the error situations in this context is that the
expansion can lead to a result that is too large to handle for the server
(e.g. in cases of high mutiplicities on CIM associations). The recovery for
this situation is that the client specifies less expansions in the first
request issues subsequent requests for separate expansion (one per
reference, which can then be paged into multiple responses in case of high

So it is not the typical server-side recovery, where the client waits for
less load on the server or the server admin needs to add more resources to
the server. The recovery attempt can be immediately decided upon by the
client without any change in server configuration or workload.

We'd like to have a HTTP status code that allows the client to detect this
situation so it can recover from it. In order to make it easy for the
client, I think that should not be a use of status code 500, but its own
status code. I checked all status codes on the IANA HTTP status code
registry and found no one that matched this situation. But I found that the
HTTP WG is working on an RFC for additional HTTP status codes that is
currently in draft :-)

So my questions to you and the WG are:
   - Do you have a recommendation on how to handle this situation?
   - How is your view on the idea to add an HTTP status code for "response
   too large"?

PS: If you're interested in CIM-RS, what you find currently on the DMTF
site or when googling it are informational specs from an incubator that do
not yet have the "expand" query parameter. The real specs from the CIM-RS
WG are about to be released as a Work in Progress in the next weeks.


Andreas Maier
IBM Senior Technical Staff Member, Systems Management Architecture & Design
IBM Research & Development Laboratory Boeblingen, Germany, +49-7031-16-3654
IBM Deutschland Research & Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschaeftsfuehrung: Dirk Wittkopp
Sitz der Gesellschaft: Boeblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294