Re: HTTP status code for "response too large"

Mark Nottingham <mnot@mnot.net> Wed, 18 April 2012 15:33 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 F382621F84DA for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 18 Apr 2012 08:33:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.98
X-Spam-Level:
X-Spam-Status: No, score=-9.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, RCVD_IN_SORBS_WEB=0.619]
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 s2cNYtPctHCA for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 18 Apr 2012 08:33:32 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id AA25521F85CD for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 18 Apr 2012 08:33:32 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1SKWsG-0002yW-W5 for ietf-http-wg-dist@listhub.w3.org; Wed, 18 Apr 2012 15:32:53 +0000
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from <mnot@mnot.net>) id 1SKWs3-0002xf-34 for ietf-http-wg@listhub.w3.org; Wed, 18 Apr 2012 15:32:39 +0000
Received: from mxout-07.mxes.net ([216.86.168.182]) by maggie.w3.org with esmtp (Exim 4.72) (envelope-from <mnot@mnot.net>) id 1SKWrw-0002pM-S4 for ietf-http-wg@w3.org; Wed, 18 Apr 2012 15:32:37 +0000
Received: from [172.16.11.154] (unknown [12.197.88.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E57AA22E25B; Wed, 18 Apr 2012 11:32:04 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <25172B451C65D28F02CDAB63@caldav.corp.apple.com>
Date: Wed, 18 Apr 2012 08:32:01 -0700
Cc: Julian Reschke <julian.reschke@gmx.de>, 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>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2033EB77-610A-447F-BEE6-C0B9CF53A2CF@mnot.net>
References: <OFD186EDCA.AF2D3EBA-ON852579E4.003EB3DE-852579E4.00403734@de.ibm.com> <4F8EAC1A.5000707@gmx.de> <214DE30B03E5CC7C7FE4CF6C@caldav.corp.apple.com> <4F8ED467.6020809@gmx.de> <25172B451C65D28F02CDAB63@caldav.corp.apple.com>
To: Cyrus Daboo <cyrus@daboo.name>
X-Mailer: Apple Mail (2.1257)
Received-SPF: pass client-ip=216.86.168.182; envelope-from=mnot@mnot.net; helo=mxout-07.mxes.net
X-W3C-Hub-Spam-Status: No, score=-1.1
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, RCVD_IN_SORBS_WEB=0.77, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1SKWrw-0002pM-S4 57f7fb3b954bffabef849c5e14ce02eb
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP status code for "response too large"
Archived-At: <http://www.w3.org/mid/2033EB77-610A-447F-BEE6-C0B9CF53A2CF@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/13457
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: <E1SKWsG-0002yW-W5@frink.w3.org>
Resent-Date: Wed, 18 Apr 2012 15:32:52 +0000

On 18/04/2012, at 7:59 AM, Cyrus Daboo wrote:

> 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.

This is a good illustration of How Not To Do It. 507 should have been more generic, focusing on the interface rather than the implementation (as Roy constantly reminds us).


Cheers,

--
Mark Nottingham
http://www.mnot.net/