Re: Prefer: return=representation and caching

Mark Nottingham <> Tue, 23 June 2020 00:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 479ED3A14A1 for <>; Mon, 22 Jun 2020 17:06:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.749
X-Spam-Status: No, score=-2.749 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.249, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=ihTbVWqS; dkim=pass (2048-bit key) header.b=KngDS9af
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WPTZi3ungKnK for <>; Mon, 22 Jun 2020 17:06:05 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 256503A149C for <>; Mon, 22 Jun 2020 17:06:05 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jnWOK-0002NA-7n for; Tue, 23 Jun 2020 00:02:20 +0000
Resent-Date: Tue, 23 Jun 2020 00:02:20 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jnWOI-0002MO-Up for; Tue, 23 Jun 2020 00:02:18 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jnWOG-0004ZM-TD for; Tue, 23 Jun 2020 00:02:18 +0000
Received: from compute4.internal (compute4.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id 0C9613DF; Mon, 22 Jun 2020 20:02:01 -0400 (EDT)
Received: from mailfrontend1 ([]) by compute4.internal (MEProxy); Mon, 22 Jun 2020 20:02:02 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=k JpOyhuPiiCtU+SW3TMH8a70BVWLT8g/Z2U6JabOvIo=; b=ihTbVWqS/AuIqeQ1I PnOc/zDlFfJld9wGp2YcaOG+U4TTM+amWrTM7BxJ0IxGJvS+LZId3l1XNL8pw5GR fzwQtmbi5yqd5hizJznnXhruy2uhI1wduiepa1Qze6RwqRzy/zoNKMCjd/2BmjjM MhqQr0sO4nNxqJkJUUyzcin00GDCZ1LOuUQqWnKpQZvFroohSIHVwCvhumxNgYEH lTLBpxkMpF8D++Opzj0jgRJTqA3SUv3ZnYLS8CJcHxidAYB1cxmAGOsDDDMkbWtD NbLJByR05g2AqPmj/JqOjfbc9kF4/MJOieMnx92sou7rz6goyAGBZzHZYB9TCOLC Jy96A==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=kJpOyhuPiiCtU+SW3TMH8a70BVWLT8g/Z2U6JabOv Io=; b=KngDS9afRU5zF/U0gKf2NuplrrD8QArGiPMwNrUR8IsHOWOFIJ9yefPfD iZCOsNm40R0aNxbR+LebXnGzUGsFkq/Z7y2rALSJWI4KjNci9DYUbNVVksZRpuar ejoAyH68kL+hqdgbYaLRpunFTm21YUmceXMW/EyzwryqXEdD8FQeZ0nbPT15D22V dC51zcCKxLhfWmOlu6zcLFXrIkkZcTi2g6mL1S80oAgflDdIKlK6j3Ze5p11eWLe R4CrLwsReoC0YkkgddrnVDIneBZNga75bk/lhpwOln9QgfLnx4kz1cZ/lwEiFZfd 8chPj12zd5LV9q34IDjE7a6KbUlAA==
X-ME-Sender: <xms:eEbxXt-Q-oFQ3zzjlthth1VH9nDeXkmbu9ixAiY0fA5SbFR-y2FugQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudekfedgvdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpedttddutdevudefveefudeuvedvheetueeigeevvedvjeefvdejgfejudffkeff geenucffohhmrghinhephhhtthhpfihgrdhorhhgpdhmnhhothdrnhgvthenucfkphepud duledrudejrdduheekrddvhedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghm pehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvth
X-ME-Proxy: <xmx:eEbxXhslYq26JvKxGITLs_wy6m2ylx1JjRqLbp4sVJG3LqGxyN2LYw> <xmx:eEbxXrBmZJZDj3Ey1_fpwhHZ2QbFDitt2ko-DVmxvxpYO27nxjPgUg> <xmx:eEbxXhdFJcwE4ly8DxbKTK5I90I7VZgCf7mhk56F3ZiVClQHqhrtEw> <xmx:eUbxXk08YddGglFihVjAvjMb_19a_VVH2c223NGDw4Fg-qnVyF-6RA>
Received: from ( []) by (Postfix) with ESMTPA id 0CF6E3280059; Mon, 22 Jun 2020 20:01:59 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Mark Nottingham <>
In-Reply-To: <>
Date: Tue, 23 Jun 2020 10:01:57 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Ken Murchison <>
X-Mailer: Apple Mail (2.3608.
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-9.8
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: 1jnWOG-0004ZM-TD 65a5edbfddfac65b6af9d723d91782c1
Subject: Re: Prefer: return=representation and caching
Archived-At: <>
X-Mailing-List: <> archive/latest/37810
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Hi Ken,

> On 15 Jun 2020, at 3:07 am, Ken Murchison <> wrote:
> All,
> Does Prefer: return=representation have any effect on the cacheability of PUT and/or POST responses?  I ask the question in a theoretical sense, not what is actually implemented in the wild.
> Consider a scenario where resources stored on the origin server may differ slightly from the actual resources sent in client requests, e.g. CalDAV with scheduling resources.

Just to be clear on terminology here - you mean '...from the actual representations sent in responses to clients', correct?

> For instance, a CalDAV client will typically make a request such as (Content-* headers and body not included for brevity):
> PUT /calendar/event1.ics HTTP/1.1
> Prefer: return=representation
> to avoid the extra round-trip of a subsequent GET to fetch the actually stored resource.  The server would respond with something like:
> HTTP/1.1 200 OK
> Preference-Applied: return=representation
> Content-Location: /calendar/event1.ics
> Cache-Control: no-cache, maxage=60
> ETag: abc
> Since the response body for the PUT request is equivalent to the response body for a GET request (post-PUT) on the same URI, can/should the response be cacheable?

As currently specified, PUT is not cacheable; see the bottom of <>.

That could be modified by a carefully thought out cache extension, but it would need to be specified; e.g., something like 
  Cache-Control: cacheable-put
... or maybe something more generic, like:
  Cache-Control: response-is-representation
(but probably less wordy)

> Similarly, for the same reason, a client may do:
> POST /calendar;add-member HTTP/1.1
> Prefer: return=representation
> and receive:
> HTTP/1.1 201 Created
> Location: /calendar/event2.ics
> Preference-Applied: return=representation
> Content-Location: /calendar/event2.ics
> Cache-Control: no-cache, maxage=60
> ETag: xyz
> Can/should this response be cacheable for /calendar/event2.ics?

POST *is* cacheable; see <>. Note that by this, we mean that future GET and HEADs can be satisfied by a cached POST response; future POSTSs will still write through to the origin. Also, POST caching is not widely implemented (at all).


Mark Nottingham