Set cache control in the HTTP-RPC response header#6265
Set cache control in the HTTP-RPC response header#6265cmwaters merged 5 commits intotendermint:masterfrom
Conversation
rpc/jsonrpc/server/http_server.go
Outdated
| return fmt.Errorf("json marshal: %w", err) | ||
| } | ||
| w.Header().Set("Content-Type", "application/json") | ||
| w.Header().Set("Cache-Control", "max-age=31536000") // expired after one year |
There was a problem hiding this comment.
I think there's some endpoints are not supposed to be cached, for example /status, the response will change according to current status.
There was a problem hiding this comment.
Yeah I think this is advisable. We should instead consider adding a cache policy on individual requests. Also, one year seems too large, no?
There was a problem hiding this comment.
@alexanderbez Agree with the cache policy that might need to be added. @yihuang, I will check the RPCs and add constrain to them.
There was a problem hiding this comment.
@alexanderbez Was my intuition, however, found a link to explain why set the age to one year if we see the data is immutable (but varnish cache doesn't support it)
https://ashton.codes/set-cache-control-max-age-1-year/
There was a problem hiding this comment.
Absolutely. If the response data does not change, then this makes sense 👍
Codecov Report
@@ Coverage Diff @@
## master #6265 +/- ##
==========================================
- Coverage 60.90% 60.80% -0.10%
==========================================
Files 282 282
Lines 26866 26885 +19
==========================================
- Hits 16362 16347 -15
- Misses 8804 8835 +31
- Partials 1700 1703 +3
|
|
@alexanderbez are these routes files not allowed to modify? |
|
Not sure I follow @JayT106? What do you mean exactly? Can they override the HTTP header? |
|
|
golangci-lint 2 errors related to the unused code. Can I just remove it? |
1edecb2 to
1feb651
Compare
| // Set the default response cache to true unless we see any error and any rpc request doesn't | ||
| // allow to be cached | ||
| var c = true |
There was a problem hiding this comment.
There is one other condition that we have to be wary about. For a lot of RPC requests i.e validators, consensus params, blocks and commits, if a client requests this data with a height of 0 the node responds by sending that data type at the latest height. This means that the same request of height 0 to these RPC endpoints should also over time send different responses and thus shouldn't cache the response
There was a problem hiding this comment.
Thanks for the feedback, I will check the condition and revise the logic.
There was a problem hiding this comment.
Awesome. Once this is done I think the PR should be ready to merge
There was a problem hiding this comment.
Added default height checking for these types of RPC requests.
This PR added the "cache-control" into the HTTP-RPC response header and set the cache expired time to one year
Closes #5764