Can PUT or Patch be made to return an ETag about cachecow HOT 4 CLOSED

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

from cachecow.

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

from cachecow.

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.

from cachecow.

Any comments?

from cachecow.