Re: HTTP status code for "response too large"

Cyrus Daboo <cyrus@daboo.name> Wed, 18 April 2012 15:01 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 D4B0421F84F0 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 18 Apr 2012 08:01:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.997
X-Spam-Level:
X-Spam-Status: No, score=-6.997 tagged_above=-999 required=5 tests=[AWL=3.002, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, 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 xT1QSWEIED-Q for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 18 Apr 2012 08:01:19 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id C599B21F84F1 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 18 Apr 2012 08:01:15 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1SKWMn-0007ib-HK for ietf-http-wg-dist@listhub.w3.org; Wed, 18 Apr 2012 15:00:21 +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 1SKWMe-0007cb-Mu for ietf-http-wg@listhub.w3.org; Wed, 18 Apr 2012 15:00:12 +0000
Received: from daboo.name ([173.13.55.49]) by maggie.w3.org with esmtp (Exim 4.72) (envelope-from <cyrus@daboo.name>) id 1SKWMY-0001lT-Tj for ietf-http-wg@w3.org; Wed, 18 Apr 2012 15:00:10 +0000
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id A16F525AF3A4; Wed, 18 Apr 2012 10:59:46 -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 ec3LvxGKaDAL; Wed, 18 Apr 2012 10:59:41 -0400 (EDT)
Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id BF59C25AF391; Wed, 18 Apr 2012 10:59:40 -0400 (EDT)
Date: Wed, 18 Apr 2012 10:59:37 -0400
From: Cyrus Daboo <cyrus@daboo.name>
To: Julian Reschke <julian.reschke@gmx.de>
cc: Andreas Maier <MAIERA@de.ibm.com>, Mark Nottingham <mnot@pobox.com>, IETF HTTP WG <ietf-http-wg@w3.org>, Thomas Narten <tnarten@us.ibm.com>
Message-ID: <25172B451C65D28F02CDAB63@caldav.corp.apple.com>
In-Reply-To: <4F8ED467.6020809@gmx.de>
References: <OFD186EDCA.AF2D3EBA-ON852579E4.003EB3DE-852579E4.00403734@de.ibm.com> <4F8EAC1A.5000707@gmx.de> <214DE30B03E5CC7C7FE4CF6C@caldav.corp.apple.com> <4F8ED467.6020809@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=1181
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 1SKWMY-0001lT-Tj 10a2c4519b6ab9ee358ede93fd83c92d
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP status code for "response too large"
Archived-At: <http://www.w3.org/mid/25172B451C65D28F02CDAB63@caldav.corp.apple.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/13456
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: <E1SKWMn-0007ib-HK@frink.w3.org>
Resent-Date: Wed, 18 Apr 2012 15:00:21 +0000

Hi Julian,

--On April 18, 2012 4:49:11 PM +0200 Julian Reschke <julian.reschke@gmx.de> 
wrote:

> I believe you're reading something into the definition which isn't there
> :-)
>
> Note:
>
> "...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."
>
> So that's about the payload sent with the request (such as PUT), not a
> payload generated for a response. (Otherwise 5xx wouldn't make sense
> here...)

Except that WebDAV SEARCH, sync REPORT, and CardDAV all re-use that code to 
indicate a truncation/limit applied to the response (albeit as a status 
element inside a multi-status rather than an overall response status code). 
So in that sense the cat is already out of the bag when it comes to using 
507 to indicate limits related to the response.

That said, 403 with a sensible body indicating the nature of the error is a 
good way around having to mint specific status codes for every possible 
type of error that could occur. I wonder if that should be more formally 
defined for HTTP as it is with WebDAV (the DAV:error element response).

-- 
Cyrus Daboo