adutra commented on PR #15428: URL: https://github.com/apache/iceberg/pull/15428#issuecomment-4011230555
> The only two requests that should be cached are HEAD and GET. But this rule isn't _enforced_. Nothing in the specs prevents a server from sending a `Cache-Control: private` header for other methods. And by doing so, it would break the client. I'm not saying it makes sense to do so, I'm saying that it's not fair for a server to break the client so easily. If the client's cache is designed to only handle these 2 methods and nothing else, I think the client should make sure to filter out other methods. It seems a bit pointless to me to require from servers to send the `Cache-Control` header when the client already knows what requests it can and cannot cache. > What led to this line of exploration appears to stem from trying to implement PUT or other methods, which should not be cached. Yes but in fact, the most problematic scenario for me is a `GET` request with a `range` header. If a server decides to sign the `range` header (which is imho totally valid), the client would break. The prevailing philosophy is that "the server decides what to to sign," but in reality, the server's control appears limited due to potential client-side cache issues. Again, it appears to me that, if the client already knows that it would break if the server signs some header, it's best for the client to proactively remove that header from the request to sign. But as I said, having now a good understanding of the limitations, I've already adapted Polaris to adhere to the implicit constraints. I'm leaving the ongoing work here for @steveloughran to continue, and will close #15171. -- 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. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
