Re: [Technical Errata Reported] RFC7232 (5236)

Mark Nottingham <mnot@mnot.net> Mon, 29 January 2018 01:03 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@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 99CFB12E056 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 28 Jan 2018 17:03:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.009
X-Spam-Level:
X-Spam-Status: No, score=-7.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=Qxtxy/nu; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=NoZkOQ04
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P27sg4XHkYTH for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 28 Jan 2018 17:03:48 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEAA212DA49 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 28 Jan 2018 17:03:47 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1efxoV-0002Zf-PM for ietf-http-wg-dist@listhub.w3.org; Mon, 29 Jan 2018 01:00:47 +0000
Resent-Date: Mon, 29 Jan 2018 01:00:47 +0000
Resent-Message-Id: <E1efxoV-0002Zf-PM@frink.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <mnot@mnot.net>) id 1efxoN-0002Yt-7R for ietf-http-wg@listhub.w3.org; Mon, 29 Jan 2018 01:00:39 +0000
Received: from out3-smtp.messagingengine.com ([66.111.4.27]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <mnot@mnot.net>) id 1efxoH-0004d1-Os for ietf-http-wg@w3.org; Mon, 29 Jan 2018 01:00:36 +0000
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 3F1E620B49; Sun, 28 Jan 2018 20:00:13 -0500 (EST)
Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Sun, 28 Jan 2018 20:00:13 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=8CRUoCZiKCguV7/HulV267B5JsPYu LJkhh1DKsCslsE=; b=Qxtxy/nux0DxlPyzV3IWbxMW8tDLlc8PzjxoHLPgS1sWL CQAlxMvBt98GX3Z/HEfXv8WLKBkHAqr7t6sQp4xPU7VEiSxuxqZGTMvr1QPKRf+Y ar+oqgndaZF6l1id28lVMYa4sYafXIkACanMpDau6P09+a4ZIMeSfWwNvsRNOii2 r0zqgFvX+QAxl0mdGwaNoNaVl+z4G4a1T0GFP7ayDP3JW4TEUxmvlzyoVdiWK9y7 1z6DvZdXPYAdjIU26wThHBIVKGqsr2hFN3xh5gPk57VX/wS1Fd5c6yyWX2R36SLE Kj9Cq6juJcd0XcRw2IAP16laVfzc18XzGxx541Krw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=8CRUoC ZiKCguV7/HulV267B5JsPYuLJkhh1DKsCslsE=; b=NoZkOQ04/WIJrvmz7ffZXH GcHOkxPF8TfXDlZ18sg7SVszVRg8ZcjvB/DwFN+rdtWVyl9v2+Qpgl7/y/NxbcFj Cxp2S+ZjCaPan3eLu/JH4pisdm76NYuakk71o+0tYtKyLv8LNzBj7wi0y5HpxqEd ln/VFrdn44KzMv2vDa1+FMaX8WL0a+0PWpZ7W78us6VC8KLyVDEs5igQF7rMzPL+ i9jt8UasQzjr+phaIGPQ5A9Mc52xJLpSkq/+4MO/59EhM2B/sP/wTieH1g++eBoL hTzKp8VyL8HGttGGw5ggfXX6HY3BupfQcsEewPZ9NNH1tWLZW59qafWZHSBiRegA ==
X-ME-Sender: <xms:HXJuWm8IXKsWTmg3gJw9M1d7nLDzzIRgSTiMvZjqw56hIVSVGi6qww>
Received: from [192.168.1.18] (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 6A55A7E34D; Sun, 28 Jan 2018 20:00:10 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <1516134882.3375943.1237594864.4C01254F@webmail.messagingengine.com>
Date: Mon, 29 Jan 2018 12:00:06 +1100
Cc: Roy Fielding <fielding@gbiv.com>, RFC Errata System <rfc-editor@rfc-editor.org>, "Julian F. Reschke" <julian.reschke@greenbytes.de>, Ben Campbell <ben@nostrum.com>, Alexey Melnikov <aamelnikov@fastmail.fm>, adam@nostrum.com, pmcmanus@mozilla.com, ietf-http-wg@w3.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <991B2144-B092-4CD0-B6F1-6B66E550FC5E@mnot.net>
References: <20180116155124.07618B81F2B@rfc-editor.org> <55475510-2367-435F-8719-77DFBACADE5C@gbiv.com> <1516134882.3375943.1237594864.4C01254F@webmail.messagingengine.com>
To: Chris Pacejo <chris@pacejo.net>
X-Mailer: Apple Mail (2.3445.5.20)
X-W3C-Hub-Spam-Status: No, score=-6.6
X-W3C-Hub-Spam-Report: AWL=3.090, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1efxoH-0004d1-Os 9d6957fe2c9685720ad8cec802b159cf
X-Original-To: ietf-http-wg@w3.org
Subject: Re: [Technical Errata Reported] RFC7232 (5236)
Archived-At: <https://www.w3.org/mid/991B2144-B092-4CD0-B6F1-6B66E550FC5E@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/35031
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: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

FWIW, I think the source of confusion here is taking this statement out of context:

"""However, if a resource has distinct representations that differ only in their metadata, such as might occur with content negotiation over media types that happen to share the same data format, then the origin server needs to incorporate additional information in the validator to distinguish those representations."""

The complete paragraph is:

"""There are a variety of strong validators used in practice. The best are based on strict revision control, wherein each change to a representation always results in a unique node name and revision identifier being assigned before the representation is made accessible to GET. A collision-resistant hash function applied to the representation data is also sufficient if the data is available prior to the response header fields being sent and the digest does not need to be recalculated every time a validation request is received. However, if a resource has distinct representations that differ only in their metadata, such as might occur with content negotiation over media types that happen to share the same data format, then the origin server needs to incorporate additional information in the validator to distinguish those representations."""

I.e., the statement is being made in the context of generating strong validators based only upon the message body, when the headers might also change.

Cheers,



> On 17 Jan 2018, at 7:34 am, Chris Pacejo <chris@pacejo.net> wrote:
> 
> Hi Roy and Julian, thanks for the replies.
> 
> On Tue, Jan 16, 2018, at 2:33 PM, Roy T. Fielding wrote:
>> The Original Text is about weak validators, which don't even require that
>> the content be the same. The two do not conflict.  The suggested change
>> would be incorrect.
> 
> The specific text which confuses me, from the section on weak validators, is (emphasis mine):
> 
> "However, two simultaneous representations might share the same *strong* validator if they differ only in the representation metadata, such as when two different media types are available for the same representation data."
> 
> Am I misunderstanding that this is in conflict with the example you gave?  (text/plain and application/json representations with same octets must have different strong validators.)
> 
> Similarly:
> 
> "Likewise, a validator is weak if it is shared by two or more representations of a given resource at the same time, unless those representations have identical representation data."
> 
> The "unless" clause would appear to apply to the example you gave, implying that both representations can have the same validator but need not be weak.
> 
> Thanks, Chris

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