I am in agreement about adding flexibility to the way temporary headers are included. I spent 6 hours changing code, searching the Interwebs, and…er…changing code, only to learn that my code was fine from the beginning. Turns out this Postman issue was the culprit.
In my case I am using Drupal REST API with OAuth2 authentication. Since I am using OAuth there should be no need for an X-CSRF-Token header to be sent on POST requests; but, Drupal kept insisting that it wanted to see that header. I searched everything on Drupal.org and changed every aspect of my code to figure out the problem. After reading this thread I realized that Postman was adding a Cookie header, which, in turn, caused Drupal to expect the X-CSRF-Token header. I have properly defined Authorization in Postman to use “Bearer Token”. I had no reason to expect that extra crap was being sent that only served to anger Drupal and muddle the situation.
I am one of the lucky developers who found a workaround in Postman to mitigate this behavior. For other developers who are having a problem with unwanted Cookie Headers:
First you must add your domain name to the whitelist in the Cookies modal (accessed via the Cookies link that appears below the Send button). Then, under the “Pre-request Script” section of the request, you can add the following to delete Postman cookies before sending the request:
const cookieJar = pm.cookies.jar();
cookieJar.clear(“yourdomain.name”);
Hopefully this saves at least one person the headache of figuring it out themselves. For folks who have a different type of Postman header problem, you may be toast based on the responses in this thread.