"Origin" header does not get sent to API Server

I have tested both with a business API and with a local API server (custom built in Python) and have encountered an issue when trying to send a POST request containing the “Origin” header.

It simply gets ignored by the POST tool. I am aware this header falls under the forbidden headers but why is it not possible to send it? In Postman I have no such issue and, also, the HTTP Retriever node works fine but unfortunately I can’t use Palladian nodes for licensing restrictions.

Also using the Java Snippet node to perform a POST request gives the same results.
I cannot use Python.

Hi @marcandavi2,

as you correctly pointed out, our HTTP client implementation for the REST client nodes also has a set of restricted headers which includes Origin.

Generally, it makes sense that these are restricted because only the HTTP client should manage these based on your settings (in this case, POST node settings). However, if you know what you are doing, you can lift this restriction by adding the following line to your knime.ini file.

-Dsun.net.http.allowRestrictedHeaders=true

This is also documented in the REST node description (see “Request Headers > Header key”). Please note that I assume you are on a KNIME version greater or equal to 5.1.3, 5.2.1, 5.3.0, as we changed the implementation recently.

Best, Leon

1 Like

Hi Leon,
this solution does work on AP, but I’m not convinced it may also work when I will deploy the workflow on Business Hub. Which configuration will be needed to make this change on the Business Hub (or Community Hub) as well?

Hi,
I am currently not sure about the Community Hub API, but on Business Hub you can change this via PUT request to the execution context.

PUT https://api.<hub-domain>/execution-contexts/<execution-context-id>

{
    "operationInfo": {
        "vmArgs": ["-Dsun.net.http.allowRestrictedHeaders=true"]
    }
}

You can get the ID of the execution context by visiting it in the browser (under your team’s execution resources) and then copying the ID from the URL.
After making the PUT request, all executors in the EC will restart and then the settings are applied.
Kind regards,
Alexander

1 Like

Hi Alexander,
it seems that this operation had no effect, since the PUT request had a successful outcome but the subsequent GET request to check the Execution Context parameters showed no changes in such configuration key.

Hi @marcandavi2,
That was my bad, sorry. It should be vmArguments instead of vmArgs. Can you try that?
Kind regards,
Alexander