M. J. FrombergerandGitHub
1f5e64e5b6
We should not set cache-control headers on RPC responses. HTTP caching interacts poorly with resources that are expected to change frequently, or whose rate of change is unpredictable. More subtly, all calls to the POST endpoint use the same URL, which means a cacheable response from one call may actually "hide" an uncacheable response from a subsequent one. This is less of a problem for the GET endpoints, but that means the behaviour of RPCs varies depending on which HTTP method your client happens to use. Websocket requests were already marked statically uncacheable, adding yet a third combination. To address this: - Stop setting cache-control headers. - Update the tests that were checking for those headers. - Remove the flags to request cache-control. Apart from affecting the HTTP response headers, this change does not modify the behaviour of any of the RPC methods.
Tendermint RPC
Pagination
Requests that return multiple items will be paginated to 30 items by default. You can specify further pages with the ?page parameter. You can also set a custom page size up to 100 with the ?per_page parameter.
Subscribing to events
The user can subscribe to events emitted by Tendermint, using /subscribe. If
the maximum number of clients is reached or the client has too many
subscriptions, an error will be returned. The subscription timeout is 5 sec.
Each subscription has a buffer to accommodate short bursts of events or some
slowness in clients. If the buffer gets full, the subscription will be canceled
("client is not pulling messages fast enough"). If Tendermint exits, all
subscriptions are canceled ("Tendermint exited"). The user can unsubscribe
using either /unsubscribe or /unsubscribe_all.