Handling of long query strings

[wemeetagain]

Some of the endpoints that use query strings don't play well with large numbers of validators.

eg:
GET /eth/v1/beacon/states/{state_id}/validators called with several hundred pubkeys

To work around the issue, we batch requests to these endpoints.

As I understand it, we want to use GET to take advantage of caching, and so have no standard possibility of using the request body in these endpoints.

I'm wondering if there's any place in the spec that should be standardized around handling of these issues.

Possible actions:

• Add an explicit limit on # of entries allowed
• Add mostly-duplicate POST endpoints that put query data in the request body, allowing any number of validators

[mcdee]

Batching GETs is the best option for most of the items. We do have a couple of requests that use POST instead of batched GETs, as it's in the validator endpoint set and so better performance is required.

Regarding standardisation of the limit: I think that when we looked at this we decided that a total URL length of no more than 8,000 bytes was safe. It may be worth putting that somewhere as an implementation note, but given that there could always be a cache, proxy or whatever in the way with a lower limit I don't think we are able to state that requests up to that size are guaranteed to work.

[dapplion]

• Fixed with POST endpoints for validators and validator_balances #367