Re: [core] draft-hartke-core-stateless

Christian Amsüss <> Tue, 11 September 2018 13:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3E1041286E3; Tue, 11 Sep 2018 06:40:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Klt9JeyReaDa; Tue, 11 Sep 2018 06:40:51 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DCB1A124D68; Tue, 11 Sep 2018 06:40:50 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPS id 09175417B6; Tue, 11 Sep 2018 15:40:49 +0200 (CEST)
Received: from ( []) by (Postfix) with ESMTP id 0CC2736; Tue, 11 Sep 2018 15:40:48 +0200 (CEST)
Received: from ( [IPv6:2a02:b18:c13b:8010::71b]) by (Postfix) with ESMTPSA id B84032A; Tue, 11 Sep 2018 15:40:47 +0200 (CEST)
Received: (nullmailer pid 15824 invoked by uid 1000); Tue, 11 Sep 2018 13:40:47 -0000
Date: Tue, 11 Sep 2018 15:40:47 +0200
From: Christian =?iso-8859-1?Q?Ams=FCss?= <>
To: Klaus Hartke <>
Cc: "" <>, 'Core' <>
Message-ID: <>
References: <009901d4495b$194c4f30$4be4ed90$> <> <>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="OwLcNYc0lM97+oe1"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <>
Subject: Re: [core] draft-hartke-core-stateless
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 Sep 2018 13:40:54 -0000

Hello Klaus,

On Tue, Sep 11, 2018 at 01:31:14PM +0000, Klaus Hartke wrote:
> But proxies also generate responses themselves, e.g., from cached
> responses or in case of errors (5.02, 5.04). We don't want clients to
> receive the extended token from another client or no extended token at
> all when a proxy does not support the option.

As long as the option is part of the cache key, any cached response
would need to have a matching request Extended-Token and thus would have
a matching response Extended-Token as well.

If those, by any chance, match up between two different staetless
proxies, *and* if there is a cached fresh response available, then so be
it, may the new request receive the original response. After all, it is
fresh, and the response Extended-Token returned is exactly the one
requested. If both requesting stateless proxies were stateful ones,
neither request would have a Extended-Token option, and the second
client would receive the cached request just as well.

(This is about the astronomically unlikely case of a collision in the
integrity protected tokens; it's way more likely that the stateless
proxy re-requested the resource on behalf of the very same origin if
such a cache hit happens. But still, even if, it'd be OK).

Best regards

To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom