On 27/09/22 23:01, Andy Armstrong wrote:
Hi Alex,
That makes a lot of sense, I don’t know how I overlooked that – thank
you. I also agree, logically caching a 201 response makes little sense,
and it was just an example I had that was easy to try so I used that.
I just altered the HTTP Return code so it sent 200 instead of 201, and
the result is sadly the same, I get many, many lines like this:
Unfortunately that is not enough. POST method is also not cacheable by
default. See <https://www.rfc-editor.org/rfc/rfc9110#section-9.3.3>
Consider what would happen when two clients POST different sets of data
to the same URL. Which one should the cache handle *instead* of letting
it be delivered to a server?
1664272638.44310107 10.1.1.70 TCP_MISS/200 275 POST
http://192.168.0.2:3001/InternalCommunicationServices/message/email -
HIER_DIRECT/192.168.0.2 application/json
My suspicion is still that my refresh_pattern is wrong:
refresh_pattern -i http:\/\/129.168.0.2:3001\/.* 10080 100% 43200
override-lastmod
refresh_pattern directive does not make things cacheable when they are
not. It can only extend or shrink cacheability times.
HTH
Amos
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
