Batch hardcodes ensureHttps: true, ignoring ApiClient protocol option

[jmikitova]

Summary

The Batch class unconditionally passes true for ensureHttps in its super() call:

// lib/requests/batch.js, line 25
super('POST', '/batch/', sum_timeouts(requests), true);

This means _buildRequestUrl in ApiClient always uses https for batch requests, even when the client was explicitly configured with protocol: 'http':

// lib/api-client.js, line 105
let usedProtocol = (request.ensureHttps) ? 'https' : this.protocol;

Problem

When using a local mock server (e.g., for development or testing) over HTTP, you configure the client like:

new ApiClient(dbId, token, { baseUri: 'localhost:9300', protocol: 'http' });

Non-batch requests correctly use http://. However, any Batch request ignores the configured protocol and forces https://localhost:9300, causing connection failures.

The only workaround is to mutate the ensureHttps property directly on the Batch instance after construction:

const batch = new Batch(requests);
batch.ensureHttps = false; // force-override the hardcoded value

This is unpleasant for a few reasons:

• It relies on a property that is not part of the public API and could silently break on any update.
• It requires every caller to know about this quirk and remember to apply the override.
• The inconsistency is non-obvious: the ApiClient exposes a protocol option that works for all other request types but is silently ignored for Batch.

Context

The JSDoc on Batch even says the request is "encapsulating a sequence of requests into a single HTTPS request" - which suggests the hardcoded value may be intentional. If so, it would be helpful to document why it must always be HTTPS even when a non-HTTPS protocol is explicitly configured, since this is an unexpected inconsistency between batch and non-batch requests.

---

Happy to hear if this is intentional and we're simply missing the right way to approach it. Otherwise, we'd appreciate a fix or guidance on the preferred workaround. Thanks for the great library!

[OndraFiedler]

The mechanism is intentional: As HMAC authentication signs the URL of the request (not the body), intercepting a Batch request sent over HTTP would allow a potential attacker to send (within the HMAC authentication time limit) a Batch request containing any sub-requests in its body.

Would it be possible to support HTTPS in the local mock server (e.g., using a locally trusted certificate via mkcert)?

[jmikitova]

Thanks for the explanation, that makes sense! We can definitely add HTTPS support to the local mock; we just wanted to keep the local dev setup as simple as possible, leveraging the protocol option available.

One follow-up question though: if the concern is about request interception, doesn't the same risk apply to non-batch requests? Since only the URL is signed (not the body), an attacker intercepting a POST or PUT request over HTTP could also replay or modify it within the HMAC time window. Is the reason HTTPS is only enforced for Batch because the potential damage is bigger (one request can trigger many operations at once), while an individual request is considered less risky in practice?