BUG: makeWebrequest without parameters returns BLE_HOST_TIMEOUT on fr965, vivoactive4s, epix2pro47mm

Took a lot of testing to obtain the following findings.

The issue affects at least the following devices:

Important notes:
1. In the simulator all tests work without issue.
2. Through the Music Player > Sync Menu, the watch starts looking for WIFI, then shows the menu. From here, all tests work without issue.
3. Through the Music Player > Library Menu, the watch uses the BLE to perform webrequests. From here, BLE_HOST_TIMEOUT is returned under the following conditions.

The following examples are giving BLE_HOST_TIMEOUT:

var options = {
    :method => Communications.HTTP_REQUEST_METHOD_GET,
    :headers => {
        "Content-Type" => Communications.REQUEST_CONTENT_TYPE_JSON,
        "Accept" => "application/json",
    },
    :responseType => Communications.HTTP_RESPONSE_CONTENT_TYPE_JSON,
};

Communications.makeWebRequest(url, null, options, method(:onResponse));

Communications.makeWebRequest(url, {}, options, method(:onResponse));

The following example does result in an expected response from the server without error:

Communications.makeWebRequest(url, {"test"=>"test"}, options, method(:onResponse));

So, adding a single parameter to the request makes it work.

But adding any custom header to the options dictionary and all results in the BLE_HOST_TIMEOUT:

var options = {
    :method => Communications.HTTP_REQUEST_METHOD_GET,
    :headers => {
        "Content-Type" => Communications.REQUEST_CONTENT_TYPE_JSON,
        "Accept" => "application/json",
        "device" => "Watch,
    },
    :responseType => Communications.HTTP_RESPONSE_CONTENT_TYPE_JSON,
};

Communications.makeWebRequest(url, null, options, method(:onResponse));

Communications.makeWebRequest(url, {}, options, method(:onResponse));

Communications.makeWebRequest(url, {"test"=>"test"}, options, method(:onResponse));

Due to the difference in behaviour between WIFI and BLE connected states, I assume this is a bug either in the watch firmware, or the Android application that is forwarding these requests. Is this indeed a bug? Is there a workaround? Looking forward to receive your response!