Closed cam-m closed 1 year ago
Sorry, but I've just read a bit futher into the http spec and found that:
Responses to the PUT method are not cacheable. If a successful PUT request passes through a cache that has one or more stored responses for the effective request URI, those stored responses will be invalidated (see Section 4.4 of [RFC7234]).
So my question appears to only be valid for PATCH, and probably also pertains to use of the PREFER header which can specify that the full representation is returned on success including an ETag.
From Here:
An example request specifying the "return=representation" preference:
PATCH /item/123 HTTP/1.1
Host: example.org
Content-Type: application/example-patch
Prefer: return=representation
1c1
< ABCDEFGHIJKLMNOPQRSTUVWXYZ
---
> BCDFGHJKLMNPQRSTVWXYZ
An example response containing the resource representation:
HTTP/1.1 200 OK
Content-Location: http://example.org/item/123
Content-Type: text/plain
ETag: "d3b07384d113edec49eaa6238ad5ff00"
BCDFGHJKLMNPQRSTVWXYZ
Hi @cam-m,
As you said, responses to PUT, PATCH and DELETE are not cacheable although CacheCow does the conditional validation on your behalf using 'if-' headers.
As for the patch with prefer, the case is not widely used and is not supported. Having said that, if the server returns the ETag, CacheCow must allow it flow to the client and if it does not then it is a bug. If that is the case, please open another issue with reproduction instructions.
Any comments?
Sorry it dropped off my radar for a bit @aliostad.
I tried to get PUT to return an Etag with a custom CachabilityValidator (I may have that class name spelled wrong here) but I couldn't get the Etag to reach the client for some reason.
I'll leave my use of cache cache cow doing the extra conditional get for now, but thanks for replying :)
Hi @aliostad!
For a PUT or PATCH request my cachechow enabled API returns the full server representation on success. So in terms of the representation, clients could be considered up-to-date after a successful PUT/PATCH . However to refresh their cache they must perform a redundant unconditional GET to obtain the new ETag.
Does (and if not could) cachecow support including an ETag in the response headers of successful PUT/PATCH along with the full representation?
Thanks again for this library, its very useful 👍