Re: HTTP status code for "response too large"

Julian Reschke <julian.reschke@gmx.de> Wed, 18 April 2012 14:52 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 5212A21F8596 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 18 Apr 2012 07:52:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.958
X-Spam-Level:
X-Spam-Status: No, score=-6.958 tagged_above=-999 required=5 tests=[AWL=3.641, 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 wQY32zOWsWqa for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 18 Apr 2012 07:52:00 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDB821F84DE for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 18 Apr 2012 07:52:00 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1SKWCn-0005sW-1j for ietf-http-wg-dist@listhub.w3.org; Wed, 18 Apr 2012 14:50:01 +0000
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from <julian.reschke@gmx.de>) id 1SKWCZ-0005rd-VM for ietf-http-wg@listhub.w3.org; Wed, 18 Apr 2012 14:49:48 +0000
Received: from mailout-de.gmx.net ([213.165.64.22]) by lisa.w3.org with smtp (Exim 4.72) (envelope-from <julian.reschke@gmx.de>) id 1SKWCQ-00079f-GW for ietf-http-wg@w3.org; Wed, 18 Apr 2012 14:49:45 +0000
Received: (qmail invoked by alias); 18 Apr 2012 14:49:12 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp002) with SMTP; 18 Apr 2012 16:49:12 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1/EHYxPZ7XEgabZjEIRG+HV31QF6OkEjV2aGoWoaR /IZwAi918RrKae
Message-ID: <4F8ED467.6020809@gmx.de>
Date: Wed, 18 Apr 2012 16:49:11 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Cyrus Daboo <cyrus@daboo.name>
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>
References: <OFD186EDCA.AF2D3EBA-ON852579E4.003EB3DE-852579E4.00403734@de.ibm.com> <4F8EAC1A.5000707@gmx.de> <214DE30B03E5CC7C7FE4CF6C@caldav.corp.apple.com>
In-Reply-To: <214DE30B03E5CC7C7FE4CF6C@caldav.corp.apple.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Received-SPF: pass client-ip=213.165.64.22; envelope-from=julian.reschke@gmx.de; helo=mailout-de.gmx.net
X-W3C-Hub-Spam-Status: No, score=-1.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1SKWCQ-00079f-GW 62220c1001841300246f27a0758b112a
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP status code for "response too large"
Archived-At: <http://www.w3.org/mid/4F8ED467.6020809@gmx.de>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/13455
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: <E1SKWCn-0005sW-1j@frink.w3.org>
Resent-Date: Wed, 18 Apr 2012 14:50:01 +0000

On 2012-04-18 16:40, Cyrus Daboo wrote:
> 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.

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

Best regards, Julian