You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Responses to POST requests are only cacheable when they include
explicit freshness information (see Section 4.2.1 of [RFC7234]).
However, POST caching is not widely implemented. For cases where an
origin server wishes the client to be able to cache the result of a
POST in a way that can be reused by a later GET, the origin server
MAY send a 200 (OK) response containing the result and a
Content-Location header field that has the same value as the POST's
effective request URI (Section 3.1.4.2).
idempotent POST - nothing is changed at the server, e.g. this could be a web-search form which always return the same results for the same POST arguments, just like GET. We can safely fulfill the requests from the cache, but GET requests to the same URI aren't fulfilled by the cache entry since we should use <URI + POST body> as a cache key;
non-idempotent POST, e.g. a comment for a blog. The request must be forwarded to origin server, but appropriate response can be cached by URI cache key to service following GET requests to the same resource (next visitors will just see the blog post with the new comment). POST body shouldn't be used as cache key;
Just invalidate the URI as RFC 7234 4.4 requires. Invalidation must be done as setting a flag in TfwCacheEntry, so the cache entry can be returned as stale response with appropriate warning. Location and Content-Location must be processed.
Cache behavior for the POST types should be explicitly specified in configuration file.
The text was updated successfully, but these errors were encountered:
As the RFC 7231 4.3.3 and the original discussion say, caching POSTs are quire and requires complex logic and passing the original requests to upstream anyway. The original motivation for the issue was to mitigate HTTP POST DDoS, but it's more efficient to do with #488 tracking the upstream stress condition.
Since the task is low priority, move it to backlog. The eBay's case still can be faced.
RFC 7231 4.3.3:
There are 3 cases to cache POST (see Caching POST and Caching HTTP POST Requests and Responses for details):
TfwCacheEntry
, so the cache entry can be returned as stale response with appropriate warning.Location
andContent-Location
must be processed.Cache behavior for the POST types should be explicitly specified in configuration file.
The text was updated successfully, but these errors were encountered: