aliostad / CacheCow

An implementation of HTTP Caching in .NET Core and 4.5.2+ for both the client and the server
MIT License
847 stars 172 forks source link

Can PUT or Patch be made to return an ETag #289

Closed cam-m closed 1 year ago

cam-m commented 1 year ago

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 👍

cam-m commented 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
aliostad commented 1 year ago

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.

aliostad commented 1 year ago

Any comments?

cam-m commented 1 year ago

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 :)