I would love to understand where itās failing for you and what led you to the point of knowing that it was the headers and the behaviour of the temp headers with Postman that caused it.
Iām just trying to gather more information around this to expand more own knowledge, as the thread is full of different users from different contexts. There have only been a handful of folks who have given actual details of what they are seeing.
Would you be able to expand on your use case and share some images or details of what headers were causing you issues etc.
Also, you donāt need to sign up for Postman to use the application, not really sure where you read that.
it happened to me today morning and it took me an hour to figure out, to solve it i had to do following solution : cookies link below Send button -> go there and delete all old cookies. I am not sure how the cookies were set up there though in first place.
My bad. I see the skip registration button at the bottom now. It has been some time since I used it last and must admit I donāt remember seeing that before. Iāll retract that part, and apologise after my frustration fuelled rant.
It is as others have said - certain services, APIs etc are expecting certain values in their headers, and ONLY those values.
Iām not able to give specifics about the rest of the headers, but for me, the āPostman-Tokenā appears to be the issue. I can verify this by adding and removing it in Insomnia.
That Postman-Token header and also the Cache-Control header, can be disabled in the General Settings menu. So those would be removed from the requests.
Thatās not to say itās going to solve all the issues mentioned in the thread though. Itās tough to know for sure because like I said, there hasnāt been a lot of information about the specific problems mentioned.
Thatās why Iām hoping that other people will share a bit more about the context of their own issues.
I just wasted an otherwise perfectly good morning on this piece of garbage. I have an āAuthorizationā header in my request with āBearer {{token}}ā but for some reason the temporary header has an old token that doesnāt work and now I cannot remove it. I thought it was something else until I noticed that the production environment worked, just not the test tool. Switching to a different tool until this is fixed.
Iāve also run into a situation where Iām almost certain that the temporary headers are causing an issue. Iām testing a REST API built on top of Django with the django-rest-registration module. When attempting to verify an email address through Postman, it fails 100% of the time. However, if I run the exact same command with cURL, omitting all the temporary headers, the request works fine. Disabling the no-cache and Postman Token headers do not change this behavior. Iāve not figured out which headers are causing the problem, specifically, but Iāll update if I do.
Edit - After some testing this morning, I believe the specific header thatās triggering my problem is the Accept-Encoding header. Removing that from the set of temporary headers allows cURL to successfully validate a user. Not sure if the same applies to ElasticSearch or other APIs. So Iād love a way to be able to at least turn that one off, though turning them all off would still be preferable.
I use Postman to achieve clarity so I know what Iām sending to an API. Having headers imposed is not doing anyone any favours. Please tell us when these can be switched off. The delay on this is counterproductive to your user community.
I get a response: ādetailā: āAuthentication credentials were not provided.ā even though headers are included. In the temporary headers, my Token XXX gets overriden to Bearer XXXX and I canāt figure out how to disable this override.
It should be simple to just add a checkbox next to each temporary header. Not allowing developers full control over what we are sending to our API is absurd.
Also, the fact that temp headers are not saved with the request makes it such that itās not true documentation.
Was considering upgrading to Pro because the product is great otherwise, but this is a non-starter.
I have been using postman for a long time and only recently I had the following issue:
What I do:
sending a request with a valid header āX-Auth-Tokenā to authorize my user.
What I have:
invalid token error
What I should have:
a valid request and a 200 response.
I noticed that my collection Authorization was set to āApi keyā with no value, and all my endpoints were set to āinherit auth from parentā
1st solution:
What I had to do since the Authorization section was introduced. Go to the collection > edit > Authorization, and setup the api key header here. and itās all working again.
2nd solution:
Go to your endpoint settings > Authorization > change type to āno authā (you can do that at the Collection level too)
yeah exactly the same problem. Iām trying to force my new tokens and the app keeps using old ones and does not let me override itā¦ such really annoying thing
thanks this helped a bit still something is really weird and my request is still putting a temporary header in my request event though I want to manage that in my environment
so I want to manage 2 of my cookies. but once they are used they never manage to be updated and my override is always ignored and the temporary overrides them
just to explain what I want to do:
I need to get a first token from a request, use that token on another request and get the updated token from the second request in the subsequent requestsā¦ this seems to be a problem because once the value is set it never gets updated
Unfortunately, Postman has become unusable, I do HTTP request testing to figure the response of the server on various headers and hence need to control all the headers.
Reading through this thread I see the frustration of the community and Postman team quite proud of the mess. I wonder if this āfeatureā was covert sabotage by Postmanās rival.
I am sad to see Postman go for me and my whole team. This feature has cost days of lost time, escalation to upper management, and simply makes no sense.
I am not sure if anyone has tried this but if you will pass temporary headers name in your header section and leave the value as empty then postman will not pass any temporary header for that.
Like many others in this thread, I spent a decent amount of time trying to figure out why a Postman request was failing, and it turns out itās because the client is sending superfluous http headers.
I then spent a decent amount of time finding and reading this entire threaded discussion. Iām now super frustrated, but I want to be empathetic and respectful in hopes of appealing to someoneās sense of reason.
@richjenks said it best, it really is āan absolutely bonkers design decisionā to add headers automatically (other than that which is necessary) with no mechanism to disable that behavior.
@abhijit The only data required for a valid HTTP request is the method, the Host header, the Path, and the protocol version. Content-Length if thereās a body. Everything else is optional. If you think otherwise then you donāt know the HTTP protocol.
What happens when an HTTP server is specifically designed to reject requests with a user-agent header. Is Postmanās official position that its client canāt and wonāt transact with that kind of server. This whole thing really is ridiculous and that the injection of headers canāt be disabled is insulting.
With respect, thereās no justification for this. Do better!
