Support capabilities when using the HTTP API

[milesj]

While capabilities are a gRPC only feature, it would be nice if the HTTP API also supported returning what capabilities are available, probably under a /capabilities route.

Right now, we have no way of knowing what features downstream users are using. Do they have zstd enabled? What's their max upload size? So on and so forth.

/status doesn't provide all the information that we need.

[mostynb]

Hi, is there a specific list of settings you need to be able to query?

[milesj]

The primary settings are what digest functions and compressors can be used.

The other capabilities I can set to defaults or force enable them (like cas/ac stuff) since it's always enabled.

[mostynb]

If we add a new /capabilities endpoint, then it would be good to report the same or similar things as the CacheCapabilities gRPC API. I filed bazelbuild/remote-apis#325 to try to get a MaxBlobSizeBytes field added to the CacheCapabilities API.

Bazel-remote only supports a single digest function (SHA256), so there's not much to gain by querying for that.

Re compressor support, clients can test that compressed uploads are supported by uploading a small blob compressed with zstandard. If that is successful then you know that zstdandard uploads are accepted. There is no need to query for zstandard download support with the HTTP API, because clients can always specify zstd in the Accept-Encoding header in the GET request.

[milesj]

@mostynb A lot of that assumes the client knows that the server is bazel-remote. I'm building a client where the user hosts their own server, and the server can be anything, with bazel-remote being one such option.

In the end, I may have to require a setting/argument that explicitly sets the server impl they are running, just to make things easier.

[mostynb]

I suppose you could probe for the digest function by uploading a small blob with various digest functions using the HTTP API, and see which are accepted.