Re: HTTP status code for "response too large"

Cyrus Daboo <cyrus@daboo.name> Wed, 18 April 2012 14:43 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE10221F85B7 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 18 Apr 2012 07:43:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.646
X-Spam-Level:
X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[AWL=4.953, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 BzhfcPVEstX8 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 18 Apr 2012 07:43:09 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8F521F85B5 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 18 Apr 2012 07:43:09 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1SKW4D-000190-7c for ietf-http-wg-dist@listhub.w3.org; Wed, 18 Apr 2012 14:41:09 +0000
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from <cyrus@daboo.name>) id 1SKW3z-000184-Fe for ietf-http-wg@listhub.w3.org; Wed, 18 Apr 2012 14:40:55 +0000
Received: from daboo.name ([173.13.55.49]) by maggie.w3.org with esmtp (Exim 4.72) (envelope-from <cyrus@daboo.name>) id 1SKW3q-0001Bk-PM for ietf-http-wg@w3.org; Wed, 18 Apr 2012 14:40:53 +0000
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 3A5C225AEF6D; Wed, 18 Apr 2012 10:40:24 -0400 (EDT)
X-Virus-Scanned: amavisd-new at daboo.name
Received: from daboo.name ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id th-jbJ2Bpof6; Wed, 18 Apr 2012 10:40:18 -0400 (EDT)
Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 54FD125AEF59; Wed, 18 Apr 2012 10:40:16 -0400 (EDT)
Date: Wed, 18 Apr 2012 10:40:13 -0400
From: Cyrus Daboo <cyrus@daboo.name>
To: Julian Reschke <julian.reschke@gmx.de>, Andreas Maier <MAIERA@de.ibm.com>
cc: Mark Nottingham <mnot@pobox.com>, IETF HTTP WG <ietf-http-wg@w3.org>, Thomas Narten <tnarten@us.ibm.com>
Message-ID: <214DE30B03E5CC7C7FE4CF6C@caldav.corp.apple.com>
In-Reply-To: <4F8EAC1A.5000707@gmx.de>
References: <OFD186EDCA.AF2D3EBA-ON852579E4.003EB3DE-852579E4.00403734@de.ibm.com> <4F8EAC1A.5000707@gmx.de>
X-Mailer: Mulberry/4.1.0a3 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; size=1579
Received-SPF: none client-ip=173.13.55.49; envelope-from=cyrus@daboo.name; helo=daboo.name
X-W3C-Hub-Spam-Status: No, score=-1.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01
X-W3C-Scan-Sig: maggie.w3.org 1SKW3q-0001Bk-PM 2fb2771c645649857b230894a166d119
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP status code for "response too large"
Archived-At: <http://www.w3.org/mid/214DE30B03E5CC7C7FE4CF6C@caldav.corp.apple.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/13454
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <E1SKW4D-000190-7c@frink.w3.org>
Resent-Date: Wed, 18 Apr 2012 14:41:09 +0000

Hi Julian,

--On April 18, 2012 1:57:14 PM +0200 Julian Reschke <julian.reschke@gmx.de> 
wrote:

>> 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"?
>> ...
>
> First of all, it's not really a server error; it's the client request
> that needs to change; thus I believe it should be a 4xx.
>
> Also, WebDAV (RFC 4918) has a similar case where servers may choose not
> to honor too complex PROPFIND requests. In this case, the server just
> sends a 403 Forbidden, and the response body contain sufficient
> additional information for a protocol-aware client to understand what
> happened. Maybe that would be an alternative.

Also WebDAV defines 507 (Insufficient Storage) as:

11.5.  507 Insufficient Storage

   The 507 (Insufficient Storage) status code means the method could not
   be performed on the resource because the server is unable to store
   the representation needed to successfully complete the request.  This
   condition is considered to be temporary.  If the request that
   received this status code was the result of a user action, the
   request MUST NOT be repeated until it is requested by a separate user
   action.

Seems like that would be a good fit (with perhaps a response body with some 
more specific information related to the nature of the failure). We already 
have various WebDAV operations making use of that to signal truncation of 
responses and other such things.

-- 
Cyrus Daboo