Re: p1: generating "internal" errors

Mark Nottingham <mnot@mnot.net> Sat, 20 April 2013 07:07 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 9365121F8F43 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 20 Apr 2013 00:07:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.508
X-Spam-Level:
X-Spam-Status: No, score=-10.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 lSPcPSUEHclD for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 20 Apr 2013 00:07:10 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0DDCF21F8F05 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sat, 20 Apr 2013 00:06:55 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UTRsc-00061c-Jp for ietf-http-wg-dist@listhub.w3.org; Sat, 20 Apr 2013 07:06:38 +0000
Resent-Date: Sat, 20 Apr 2013 07:06:38 +0000
Resent-Message-Id: <E1UTRsc-00061c-Jp@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <mnot@mnot.net>) id 1UTRsZ-00060s-Hv for ietf-http-wg@listhub.w3.org; Sat, 20 Apr 2013 07:06:35 +0000
Received: from mxout-08.mxes.net ([216.86.168.183]) by maggie.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <mnot@mnot.net>) id 1UTRsY-0006F5-6K for ietf-http-wg@w3.org; Sat, 20 Apr 2013 07:06:35 +0000
Received: from [192.168.1.80] (unknown [118.209.190.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0F887509B5; Sat, 20 Apr 2013 03:06:11 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <20130420070354.GH26517@1wt.eu>
Date: Sat, 20 Apr 2013 17:06:08 +1000
Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <508475A0-4D1A-491B-AB1F-D9D1D9525D35@mnot.net>
References: <EA721AC2-5655-4EC6-851B-303EE22BB670@mnot.net> <20130420070354.GH26517@1wt.eu>
To: Willy Tarreau <w@1wt.eu>
X-Mailer: Apple Mail (2.1503)
Received-SPF: pass client-ip=216.86.168.183; envelope-from=mnot@mnot.net; helo=mxout-08.mxes.net
X-W3C-Hub-Spam-Status: No, score=-3.4
X-W3C-Hub-Spam-Report: AWL=-3.376, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1UTRsY-0006F5-6K 007e7805d387165d4315419024f19fbc
X-Original-To: ietf-http-wg@w3.org
Subject: Re: p1: generating "internal" errors
Archived-At: <http://www.w3.org/mid/508475A0-4D1A-491B-AB1F-D9D1D9525D35@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17391
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>

On 20/04/2013, at 5:03 PM, Willy Tarreau <w@1wt.eu> wrote:

> On Sat, Apr 20, 2013 at 02:07:52PM +1000, Mark Nottingham wrote:
>> p1 3.2.4 requires that a syntax violation in a received response be turned
>> into a 502 (Bad Gateway) status code.
>> 
>> I'm not necessarily against it, but I think if we're going to take this
>> approach to errors in received responses, it should be systematic, and we
>> should recommend that others do it too. Currently, a lot of people are
>> inventing new pseudo status codes to fill this role.
>> 
>> What do people think?
> 
> haproxy does exactly this right now (502) and I was not aware that people
> invent their own code, this is pretty bad :-(

I'm thinking more about client libraries than intermediaries.


>> This might not result in any changes in our specs beyond adjusting language
>> in a few other places to do the same thing. I could see writing a separate
>> spec for a header that described the type of error, though.
> 
> Good idea. Alternatively the reason code after the 502 could be modulated too.


That is discarded in some circumstances, and in any case we shouldn't encourage people to start using it for semantically significant things...

Cheers,

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