Prefer: return=representation and caching

[Ken Murchison <[e-mail]>]

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