Custom headers ignored in external requests

Hi all,

When issuing a request from a V8 script service, it seems the options object is ignored. We’ve tested it in DF 2.2.0 and 2.2.1.
For example, the following code:

var options = {
    headers: {
        'X-MyHeader': 'Test'
};"http://localhost:55555/posttest", JSON.stringify({a: 1}), options);

Sends the following request to localhost:

POST /posttest HTTP/1.1
Host: localhost:55555
Accept: */*
Content-Length: 7
Content-Type: application/x-www-form-urlencoded


According to the V8 scripting documentation, the headers should be generated but I don’t see them in the received request.

Any idea why the custom header option is ignored?

Thanks in advance.

Could this be a bug, @benbusse?

This is fixed in the 2.4 release. 2.4 is on github now and the bitnami
installer will be available next week.

Thanks for the quick response. Migrating from v2.2 to v2.4 in our production system sounds scary. Is there any kind of patch or hotfix that solves this problem and can be applied on v2.2.0 or v2.2.1?

Patching is risky. This change is in df-core repo. Updating df-core will affect other packages, so a full update is recommended here.

You could also apply the patch by manual coding, but that’s not recommended…particularly in a production environment.

Thanks for the honest recommendation.

Besides the custom header issue, I think there’s also something wrong about the processing of the URL used to request with platform.api. I’m still talking about DF 2.2, and maybe both issues are related.

When using platform.api to request any other URL different from the one used to request to the service, I always receive an exception (Executed command returned with error code: 1 when using a NodeJS service).
For example:

  • A NodeJS service (let’s call it myservice) receives an external request as GET (with the corresponding API key and session token).
  • From within the service, let’s say we issue a request to another service with an API key in the query string which has the corresponding permissions. I guess adding the API key in the URL as a query string is a workaround the header problem in server scripts. E.g: POST to
  • The problem comes when using an alias URL of the same server, such as or http://localhost:8080/api/v2/mongodb/_table/myTable?api_key=blahblah. For some reason the call to always returns an error.

I understand the latter request is considered as an external request, but it seems that the function gives an error even before sending the request out (we’ve tried listening on localhost).

¿Is this another known issue? ¿Maybe because, like in the example we tried to issue a HTTP request from an HTTPS request?

Actually I think the issue happens depending on the source of the request:

  • If the initial request came from a HTTPS URL (e.g. API docs) our service (which calls platform.api to call other services via relative paths) works.
  • If the initial request came from a HTTP URL, our service returns:
    Executed command returned with error code: 1

This was another issue now fixed in Version 2.4.