Frustrating Day with Postman – Problems Log – 1/4/2019

Postman is my go-to tool for testing a new API, replaying HTTP requests, and general mucking about with network requests. They call their tool a “API Development Environment”, and if you deal at all with APIs and/or endpoints like webhooks, you should check them out. In general I am a fan, and have been for some time now, but today I have been running into a seemingly endless supply of roadblocks trying to get something simple working. I thought I would jot down what I ran into, some of which is my own fault, and some is partly due to how Postman is designed.

In no particular order:

Postman refuses to load on Windows / crashes / GUI screen flashes white and black / glitches out

The problem:

This problem actually started a while ago for me (at least how I remember it), but seems to have gotten progressively worse. At first Postman would just take an incredibly long time to launch, and would flash a bunch and hang for a while until it finally loaded. However, today it started its normal glitching out when trying to launch, but then seemed to never load and basically crashed.

The Fix:

I assumed this would be complicated to fix, but actually it is very simple. This is a known issue with how Postman uses certain GPUs, and you just need to set a global system environmental variable that tells Postman to avoid using the GPU. See screenshot below (click for larger version):

Alternatively, if you are feeling lazy and want an even faster route, launch a Windows Command Line window with Administrator rights and run this command:

setx -m POSTMAN_DISABLE_GPU "true"

A POST request was working with the body set as “raw”, but not with the body set to “x-www-form-urlencoded” or anything else

The problem:

Pretty much exactly what the heading says. I was trying to get a simple POST request to work, which I had imported from Chrome. It would work if I used “raw” as the body content, but whenever I tried to send the exact same body content but as form-data or x-www-form-urlencoded instead, I would get unexpected results.

More details:

This was actually my bad (well mostly). I had created my request in Postman by using Chrome’s “copy as cURL (bash)” and then using the import feature in Postman. However, by default this only copies the body as raw, and Postman doesn’t seem to be able to auto-parse the raw into form-data, so I had manually copied and pasted from the “Form Data” panel in Chrome network requests to the “Bulk Edit” field editor in Postman -> x-www-form-urlencoded. What I missed is that Chrome includes a space between key and value pairs in the dev panel, which got pasted into Postman. Since Postman doesn’t use trim() in parsing the Bulk Edit input, the value got passes as a literal space before each value. So what should have been sent as something like:

myProp=myVal

… was getting sent as:

myProp= myVal

The fix:

The easy fix here was simply to find and replace “: ” with “:” before pasting from Chrome into Bulk Edit. However, this could maybe be fixed by using Postman Pre-Request Scripts.

Postman console not matching actual requests

The problem:

This was a strange one. I was trying to figure out why a request wasn’t working, and I wanted to see the actual request once it left Postman, so I opened up the Postman Console, which conveniently logs requests and lets you inspect them after you hit “Send”.

I was dumbstruck when I noticed that, according to the console, Postman was sending key-value pairs in my request body that I had very specifically DISABLED / unchecked in the Postman GUI. What the heck? I tried a few different things (making sure I didn’t have duplicate key/value pairs, trying different variations), but I kept seeing unchecked and disabled value pairs showing up in the Postman console.

I finally got frustrated and wanted to verify that the console itself was making sense. So I changed the endpoint I was working on to a RequestBin endpoint (a service that gives you a URL you can make requests to and it logs them online for you to inspect). I then made the same request and compared the Postman console with the actual request that came through to RequestBin. They didn’t match – Postman’s Console did not match the ACTUAL request sent and received!!! RequestBin showed what I wanted, that Postman indeed was not sending values I had unchecked, but that still didn’t explain why the console was incorrectly showing those being sent. ARGH!

The fix:

As much as my gut reaction is to blame myself (PEBKAC, blah blah), this appears to either be an actual legitimate bug, or poorly documented functionality that I would argue goes against user expectation. As of right now, I see multiple bug reports (here, here, and here) on Github that are about this exact issue, which reassures me that I’m not crazy (at least in this instance).

The quick and dirty fix, if you simply want to see EXACTLY what Postman actually sent as a request, is to add a “Pre-Request Script” and/or “Test Script” that includes the following:

console.log(request);

Whereas the default request logging that Postman does seems to suffer from this bug, the “request” variable actually does represent the real request that gets sent, and does not show things like unchecked variables. I would recommend putting the console.log(request) in the “Test” script panel, since that one runs after the request executes, so it should be the most accurate.