- From: Ken Murchison <murch@fastmail.com>
- Date: Sun, 14 Jun 2020 13:07:54 -0400
- To: ietf-http-wg@w3.org
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
Received on Sunday, 14 June 2020 17:08:09 UTC