Disable Temporary Headers

It doesn’t go far enough
 I too have been looking for a way to deactivate these temporary headers. The reason? CORS.

I am trying to test an API and I suspect that the reason my requests are being rejected is because the “Temporary” headers being sent by Postman are not included in the list provided by the API’s “Access-Control-Allow-Headers” header.

As I’ve read here, I can’t turn these off
 so I’m stuck! I will have to go and find something else to send these requests.

My advice: allow people to send really, really, raw requests.

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.

Dear all,

Upcoming canary release will show all headers that will go out and that too even before you hit send. You’ll also have the ability to turn off all headers except two - connection and host. Live Preview on Canary

1 Like

Hey @daniel.thorne @DiversiCon!

We’ve published a new version of Postman Canary with improvements to the Live Preview feature that should help with what you’re asking for.

Please read the FAQ and provide any feedback you have there so we can centralise everything in the same thread:

1 Like

Hey everyone :wave:

Live preview is now generally available! If you’ve already updated to the latest version you may have noticed some changes to how headers are displayed or added. Read more about it here:

2 Likes

Hi, I’m coming here in September 2020 and I’m not sure if it’s fixed or not, as all my requests started to fail after shifting from the chrome app to the standalone version. I cannot send anything without my server refusing them. Do we have an update on this?

Hey @thethiny

Welcome to the community. :wave:t2:

The temporary headers have been removed from the app.

I would recommend creating a new thread and explaining your specific issue in detail so that people can help you reach a solution.

1 Like

Thank you for the reply. It must be something else then that’s causing postman to fail. I’ll have a look in my free time. Thanks.

People are here to help you out but you would need to explain your specific issue in more detail, as not all issues are the same.:trophy:

I don’t think this is the thread to do that in, that’s why I suggested creating your own :grin:

Moving from chrome app to the native app can cause certain issues with cookies etc. I would take a look at clearing the cookies in the app and seeing if that helps.

I literally don’t know anything about your requests or the API you’re hitting so without more context, it’s just a guess at this point. :confused:

Thank you @danny-dainton I understood this. I didn’t update to the latest version as I have rolled back to the Chrome app, and as I stated I didn’t test it yet. I didn’t create a new thread as I didn’t know if this one was solved yet or not, so I wanted clarification before downloading the new version again.

January 2021, Version v7.36.1 Still Cannot disable Cookie from Header.
Spent 3 hours trying to figure out why my app gives a different response than the Postman client.

Hey @shashank.degloorkar, there are examples of how to disable the different entities (including cookies) in that post: Live Preview on Canary - #2 by arlemi

Please refer to it and let us know if you still can’t find how to do it.

1 Like

I spent hours today trying to figure out why several of my APIs are returning 404s, 401s, etc. None of them are broken, but I momentarily freaked out when Postman was reporting issues. I tried the exact same endpoints in Python and curl without any problems at all. I turned off everything I could click, but it’s not working. I can’t believe I paid for a tool that is harder to use than curl. Using apitester.com shows the issue plainly and immediately because it actually works without any of the fluff. I am befuddled that a tool for developers is not more developer friendly. What an incredibly bad decision.

Hey @anthonyandriano

Which version of the app are you using as the Temporary Headers haven’t been part the app for a long time now?

These are automatically generated, like they always have been but you have full control over each one of them.

Is I am developing my API it’s up to me the decision to to send or not the headers. It’s my decision if i want to send incorrect content lenght, for exemple. It’s not a postman decision. If I want to not be compliant with RFC, is not a postman business. So why i use insomonia.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.