[GitHub] [trafficserver] bneradt commented on issue #7839: POST method request will delete existing cache

[GitBox <gi...@apache.org>]

bneradt commented on issue #7839:
URL: https://github.com/apache/trafficserver/issues/7839#issuecomment-844275083


   I've written an AuTest that reproduces this on  a local branch. I'm now considering how ATS's behavior should change.
   
   I agree with @bryancall 's comment: that is, we should delete the cached entry if a 2xx is received from the server to a POST. The problem with keeping the cached content valid is that the POST potentially invalidates the resource because POST is an unsafe method.
   
   Consider this sequence:
   1. A client performs a GET request for resource A.
   2. The server responds and we cache the response.
   3. A client performs a POST request for the same resource, resource A.
   4. The server updates its state for A. Future GET requests for A now receive a different value from the server than the one responded to in step 1 above.
   5. A client repeats step 1, performing a GET request for resource A.
   
   How should ATS respond to this GET request? It should not serve out of the cache the response received from the server in step 2 since that response has been invalidated.
   
   However, we don't want to invalidate such entries to previous GET requests if the POST failed (i.e., if the server responds with a non-2xx response). That would be too aggressive, and that is what we currently do.
   
   The RFC seems to describe this proposed behavior here:
   
   https://datatracker.ietf.org/doc/html/rfc7234#section-4.4
   
   >    Because unsafe request methods (Section 4.2.1 of [RFC7231]) such as
   >    PUT, POST or DELETE have the potential for changing state on the
   >    origin server, intervening caches can use them to keep their contents
   >    up to date.
   > 
   >   ...
   > 
   >    A cache MUST invalidate the effective request URI (Section 5.5 of
   >    [RFC7230]) when it receives a non-error response to a request with a
   >    method whose safety is unknown.
   > 
   >    Here, a "non-error response" is one with a 2xx (Successful) or 3xx
   >    (Redirection) status code.  "Invalidate" means that the cache will
   >    either remove all stored responses related to the effective request
   >    URI or will mark these as "invalid" and in need of a mandatory
   >    validation before they can be sent in response to a subsequent
   >    request.
   > 


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org