Re: #461, was: p4: editorial suggestions

Julian Reschke <> Mon, 06 May 2013 06:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 625BF21F8D27 for <>; Sun, 5 May 2013 23:33:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id B2qtPpKMLAoD for <>; Sun, 5 May 2013 23:33:23 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8272021F8DFC for <>; Sun, 5 May 2013 23:32:35 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UZEwp-0004Bd-1p for; Mon, 06 May 2013 06:30:55 +0000
Resent-Date: Mon, 06 May 2013 06:30:55 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UZEwb-0004AH-Su for; Mon, 06 May 2013 06:30:41 +0000
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UZEwb-0001te-3N for; Mon, 06 May 2013 06:30:41 +0000
Received: from ([]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0LobVE-1U6EuK29Qw-00gU8s for <>; Mon, 06 May 2013 08:30:14 +0200
Received: (qmail invoked by alias); 06 May 2013 06:30:12 -0000
Received: from (EHLO []) [] by (mp001) with SMTP; 06 May 2013 08:30:12 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX18RnUZxY3URuXGGS+iq/gD/sTHcy/W1ZT0eDABPXd xmhRXLvJ7oDpYG
Message-ID: <>
Date: Mon, 06 May 2013 08:30:03 +0200
From: Julian Reschke <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Mark Nottingham <>
CC: Ken Murchison <>,
References: <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.4
X-W3C-Hub-Spam-Report: AWL=-2.483, BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1UZEwb-0001te-3N 8bc6cbf0608a4ccf961a684e96dc51c2
Subject: Re: #461, was: p4: editorial suggestions
Archived-At: <>
X-Mailing-List: <> archive/latest/17843
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On 2013-05-06 04:28, Mark Nottingham wrote:
> On 02/05/2013, at 5:05 PM, Julian Reschke <> wrote:
>> On 2013-05-01 01:26, Mark Nottingham wrote:
>>> On 01/05/2013, at 12:46 AM, Ken Murchison <> wrote:
>>>> On Tue, 30 Apr 2013 15:07:49 +0200, Julian Reschke wrote:
>>>>> On 2013-04-23 05:47, Mark Nottingham wrote:
>>>>>> * 3.1 "...instead they MUST respond with the 412 (Precondition Failed) status code."  This is too strong; e.g., what if authentication is needed? Suggest an "unless..." clause allowing other error status codes.
>>>> The first paragraph of Section 5 seems to address the case of 401 and any other errors:
>>>> "For each conditional request, a server must evaluate the request preconditions after it has successfully performed its normal request checks (i.e., just before it would perform the action associated with the request method). Preconditions are ignored if the server determines that an error or redirect response applies before they are evaluated. Otherwise, the evaluation depends on both the method semantics and the choice of conditional."
>>>> The second sentence in Section 3 references Section 5 as far as when preconditions are applied.  This seems sufficient to me, but perhaps that is because I have read the document several times and know what it says in its entirety.
>>> Unfortunately, some (many) people will read the MUST and just stop.
>> Not convinced. We could move the text into each status code description, but I don't think it makes things much clearer.
>>> Also, everywhere else we suggest the most sensible status code to use in a situation, barring exceptions (which is essentially what we're doing here), it's SHOULD; the MUST here seems sorely out of place.
>> Why?
> Here's a small sample of similar requirements in p2 (there are many, many more):
> * When a request method is received that is unrecognized or not implemented by an origin server, the origin server SHOULD respond with the 501 (Not Implemented) status code.
> * When a request method is received that is known by an origin server but not allowed for the target resource, the origin server SHOULD respond with the 405 (Method Not Allowed) status code.
> * If one or more resources has been created on the origin server as a result of successfully processing a POST request, the origin server SHOULD send a 201 (Created) response containing a Location header field that provides an identifier for the primary resource created (Section 7.1.2) and a representation that describes the status of the request while referring to the new resource(s).
> * 4.3.4 "If the target resource does have a current representation and that representation is successfully modified in accordance with the state of the enclosed representation, then either a 200 (OK) or 204 (No Content) response SHOULD be sent to indicate successful completion of the request."
> What makes this one a MUST but the rest SHOULDs? Or are we just using these terms completely arbitrarily?

a) For some of these, MUST may be better.

b) It always has been MUST, why change it?

And most importantly:

c) A conditional header field may be used to protect a potentially 
destructive request to change a resource that has been updated in 
between. Clients must be able to rely on that this protection works (and 
they do rely on it now), so it is a MUST fail. The also rely on a 
specific status code being returned in this case for diagnostics, so I 
believe it has to remain a "MUST fail" with this specific code.

Best regards, Julian