Disable Temporary Headers

[rkundalya]

I have noticed that new version on Postman is having a section called “temporary Headers”.
Is there a way to disable that.

[shamasis (Shamasis Bhattacharya)]

You want to disable sending the headers or stop showing it. We have just released a patch that hides it by default.

If you want to disable sending the temp headers, I’m afraid that is not possible since Postman is adding headers that it thinks is required for the request to go through, which otherwise you’d have had to provide manually. This is same as browsers / other clients do.

[liguoqinjim (Guoqin Li)]

But when I just want to test the request without cookie.How can I do?
The temporary headers will always add the cookie to the request.

[richjenks]

The whole point of Postman is to mock HTTP requests, not browsers. I’ve used Postman for years but if unwanted headers are being forced upon me then I’ll have to find an alternative tool like Insomnia.

It’s an absolutely bonkers design decision to add headers no-one wants and make it impossible to remove them. It will make testing APIs impossible because we can’t control what’s actually being sent. Not to mention cookie issues. What were you thinking?!

[abhijit]

@liguoqinjim @richjenks There has been no change in the behaviour of the app. Headers like Host/Content-Length/Cookie have always been added to the request - they were just not visible to the user.

These are now shown (under the Temporary Headers section) in the interest of lettings users see exactly what is being sent.

The Host header is not something “no-one wants”. According to https://tools.ietf.org/html/rfc2616, the client must add the header.

Are you seeing any change in behaviour as far the actual API response is concerned?

[richjenks]

@abhijit User-Agent, Accept, cookie, accept-encoding and Connection are headers I do not want to be added to requests unless specified.

Are you arguing that it’s desirable to have cookies added against your will?

[abhijit]

@richjenks These headers were always added to the request (even in previous versions of the app), but not shown. I’ve added a screenshot showing an older version of Postman making a request. There’s nothing visible in the headers section of the app, but you can see the Accept/Cookie headers being sent in the actual request (on the right).

Not including specific headers is a different problem, and one that will need to be solved differently for each header. The Accept/User-Agent/Host headers can be overriden manually, for example. Not sending cookies will require a separate setting / user flow.

[abhijit]

Postman 7.2.1 supports an experimental code generation mode. This can be enabled using the 'Experimental Codegen mode` flag in Postman’s global settings.

With this enabled, you’ll see a new code generation window, with bug fixes, support for two new languages (JS-Fetch and PowerShell), and the ability to customize certain aspects of the generated snippet, including the ability to show/hide temporary headers.

[bandgap]

I am actually having an issue using Postman to interact with Elasticsearch, because of the temporary headers.

I get a a 406 Not Acceptable with the following reply:
{
“error”: “Content-Type header [text/plain] is not supported”,
“status”: 406
}

The request is a POST to localhost:9200/_snapshot/my_backup with the following contents:

{
“type”: “fs”,
“settings”: {
“location”: “my_backup_location”
}
}

I can send GET requests to Elasticsearch just fine, for some reason. But for POST request, I get the rejection I have described.

I would like to use Postman to interact with Elasticsearch instead of using curl from the command line, but this header issue is forcing me not to use Postman for this purpose.

Edit: I seem to be getting a similar response when I remove the temporary headers and send the request using curl. This is potentially an Elasticsearch issue.

Sent request:
curl -X POST
http://localhost:9200/_snapshot/my_backup
-d ‘{
“type”: “fs”,
“settings”: {
“location”: “my_backup_location”
}
}’

Response:
{“error”:“Content-Type header [application/x-www-form-urlencoded] is not supported”,“status”:406}

[bandgap]

The issue is documented here:

Strict Content-Type Checking for Elasticsearch REST Requests

By changing the Content-Type header of the curl request, I was able to get the request to go through.

The command is as follows:
curl -X PUT
http://localhost:9200/_snapshot/my_backup
-H ‘Accept: /’
-H ‘Cache-Control: no-cache’
-H ‘Connection: keep-alive’
-H ‘Content-Type: application/json’
-H ‘Host: localhost:9200’
-H ‘Postman-Token: d5d262df-3320-4f7b-a19e-a326f171e432,70f47523-63a0-43d1-9f7d-3ad581ce9d2e’
-H ‘User-Agent: PostmanRuntime/7.15.0’
-H ‘accept-encoding: gzip, deflate’
-H ‘cache-control: no-cache’
-H ‘content-length: 72’
-d ‘{
“type”: “fs”,
“settings”: {
“location”: “my_backup_location”
}
}’

I just changed text/plain to application/json.

That said, there should be some way in Postman to change this setting.

[adam.l.levine (Adam Levine)]

I’m new to Postman, so I cannot speak to the 'it’s always done this, now just showing it issue". However, I came here trying to find out how to disable the temporary headers that I’m not explicitly setting.

so, +1 for disabling these beyond just the code generation aspect.

[catchsvix (Saivivekh Swaminathan)]

+1

Switching to insomnia for now. There should be an ability to not send “temporary headers”.

[ehmizmg (Ernesto Monroy)]

Agreed that this should be a feature, regardless of if it was in previous versions or not. A big part of API testing is checking how headers behave and if you cant control that on postman then you need to look for alternatives

I do hope you implement this

[kaustavdm (Kaustav)]

Thanks for all the feedback on this thread. We have slotted this on our roadmap and will ship out a fix soon.

We are exploring changing the name of “Temporary Headers”, which is TBH, confusing to many. We will add some docs to explain why these headers are needed and added by Postman. Besides that, we are also exploring introducing a settings option to disable adding these headers.

It’s still in a design prototype phase, so I don’t have anything concrete to show right now, but I will let you people know as soon as I have something on my hand.

[brant.fitzsimmons]

Disable.

Authorization headers are being added automagically. Why in the world would it do something like that? Where is it getting the values for the header?

[prabkum]

Damn! I can’t believe that the tool whose sole aim is to aid the development of APIs forces some request headers and doesn’t allow them to be disabled. The server I am sending request to doesn’t like gzipped Content-Encoding but Postman sends my content gzipped by default and sets a Content-Encoding header! The server doesn’t understand what’s reaching it!!!

[danny-dainton]

Hey @prabkum,

Have you tried using something like this in the Pre-Request Script to change the header being sent:

pm.request.headers.upsert({key: 'accept-encoding', value: '*'})

Or

pm.request.headers.upsert({key: 'accept-encoding', value: ['identity', 'br']}) 

These are just examples but you could use the same method to set that header to the value that the server accepts.

[l1ghtman (Айбек Жылкайдаров)]

I tried to use postman for one of the CTFs. It took me 4 hours to realize that this was due to postman’s temporary headers that I was getting my requests denied.

I strongly think that temporary headers should be optional, otherwise this just limits the capabilities of Postman as an API tool in general, and forces an entire userbase to look for a different solution

[zethon]

I just downloaded Postman a couple hours ago and was using it until I noticed the headers that it was adding to every request. I ended up here when I tried to figure out how to disable them and I’m dumfounded how there is no option in a REST API development tool to disable headers that are sent with every request.

MAYBE if it was a feature in a paid version of the software then I could understand, but the fact that this is just how it is? Absolutely ridiculous, and it makes the tool inferior to something as simple and basic as Advanced REST Client, which I will go back to using.

[manuka_m (Manuka Maduranga)]

Im sorry but it is a horrible decision to not allow the option to remove these temp headers. I can’t use postman now because it forces the cookie header when I actually want to remove it. Who made this design decision?