Re: Prefer: return=representation and caching

Hi Ken,

> On 15 Jun 2020, at 3:07 am, Ken Murchison <murch@fastmail.com> 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 <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)


> 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 <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/

Received on Tuesday, 23 June 2020 00:02:19 UTC