Re: #461, was: p4: editorial suggestions

Julian Reschke <> Mon, 06 May 2013 07:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 796E021F8EB1 for <>; Mon, 6 May 2013 00:20:05 -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 Qn-98ghqnM8Q for <>; Mon, 6 May 2013 00:19:59 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D557A21F8EAF for <>; Mon, 6 May 2013 00:19:58 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UZFhO-0000Ue-Sh for; Mon, 06 May 2013 07:19:02 +0000
Resent-Date: Mon, 06 May 2013 07:19:02 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UZFhE-0000Tn-HZ for; Mon, 06 May 2013 07:18:52 +0000
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UZFhD-0004FX-Tj for; Mon, 06 May 2013 07:18:52 +0000
Received: from ([]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0Mb5Wf-1Us9Jy2jAx-00Ki5V for <>; Mon, 06 May 2013 09:18:25 +0200
Received: (qmail invoked by alias); 06 May 2013 07:18:25 -0000
Received: from (EHLO []) [] by (mp027) with SMTP; 06 May 2013 09:18:25 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1/+yYRR1P7+xUXdhSJ1EdEB6O67+5DY8IZyeN6yiv c6DPyi05n79POs
Message-ID: <>
Date: Mon, 06 May 2013 09:18:24 +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: 1UZFhD-0004FX-Tj 32d3f26d62fbd70cf7c44412a131cf59
Subject: Re: #461, was: p4: editorial suggestions
Archived-At: <>
X-Mailing-List: <> archive/latest/17845
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On 2013-05-06 08:34, Mark Nottingham wrote:
> On 06/05/2013, at 4:30 PM, Julian Reschke <> wrote:
>> a) For some of these, MUST may be better.
> I thought you were interested in keeping changes minimal... :)

I'm mainly interested to finish HTTP/1.1. This implies that we should 
now concentrate on fixing things that are broken. This does not appear 
to be broken.

>> b) It always has been MUST, why change it?
> Because strictly interpreted, it can result in leaking information about resources that require authentication (among other nonsensical conditions).

How so?

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

>> 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.
> Great; we can make it MUST NOT apply the method, as we do elsewhere in several places already, whilst making the status code to return a SHOULD.

I still don't understand the benefit, but I *do* see drawbacks.

Best regards, Julian