Subject: Prefer: return=representation and caching

From: Ken Murchison <[email-masked]>
Date: Sun, 14 Jun 2020 13:07:54 -0400

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.

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?

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?

-- 
Kenneth Murchison
Senior Software Developer
Fastmail US LLC

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 23 Jun 2020 10:01:57 +1000

Hi Ken,

> On 15 Jun 2020, at 3:07 am, Ken Murchison <[email-masked]> 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):
> 
> 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
> 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 <https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#PUT>.

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)

> Can/should this response be cacheable for /calendar/event2.ics?

POST *is* cacheable; see <https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#POST>. 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).

Cheers,

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