vpelletier edited a comment on issue #7839: URL: https://github.com/apache/trafficserver/issues/7839#issuecomment-846685665
While further investigating this issue with @fdiary, I noticed this part also in [rfc7234 section-4.4](https://datatracker.ietf.org/doc/html/rfc7234#section-4.4) (emphasis mine): > A cache MUST invalidate the effective Request URI (Section 5.5 of > [RFC7230]) **as well as** the URI(s) in the Location and Content-Location > response header fields (if present) when a non-error status code is > received in response to an unsafe request method. I was under the initial impression that POST responses should only invalidate the cache when they contain `Location` and/or `Content-Location` and than only the resources they identify would be invalidated (and not the Request URI). We now believe the original reason for the present bug report was misguided: invalidating the Request URI of a POST request is RFC-compliant, and it is up to us to direct POSTs to URIs which we do not want to invalidate. The efficiency of us changing our POST URIs kind of depends on error statuses not invalidating the resources, otherwise a malicious (...for a rather tame meaning of "malicious", I believe) client can evict arbitrary entries from the cache by sending POST requests on URIs not intended to receiving them even if they correctly reject the POST. Thanks a lot for spotting this. -- 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: [email protected]
