Show compressed body size

[Eomm]

Hi, the Size: field shows the amount of uncompressed payload:

And if I remove the response header (to avoid the uncompression of Postman) I get the size I'm interested:

Could we add a Before uncompression field?

Thanks

Related to https://github.com/postmanlabs/postman-app-support/issues/5885

[MilosRandelovic]

+1

I've spent some time trying to make my server do gzip compression automatically, and it would be nice if Postman could help me verify the actual transfer size.

[thoughtworks200]

+1

[tafia]

+1

[jonasfrid]

+1

[vaibhavpacharya]

+1

[Samreay]

@shamasis - any movement on this?

[tamirs9876]

+1

[ElliotNB]

@shamasis +1

[goriunov]

+1

[pedrotambo]

+1

[augustoicaro]

+1

[danielramireze]

+1

[lada]

+1

[wilsonssss]

+1

[goforgold]

+1

[s00pa]

+1

[dranitski]

+1

[alexkev]

+1

[raymondKelly]

+1

[MonsterMetroid]

+1

[juber-nunes]

2 1/2 years, any updates on this?

[okcthulhu]

Our team is considering switching to Insomnia for this exact reason. We need to know the uncompressed response size in order to test what's going on with API limitations from our providers. Would love to see a fix.

[kevinswiber]

Note This is not an official resolution.

A workaround I use is to either console.log the information I need or use the Postman visualizer.

Here's a script I drop in to the Tests tab to use the visualizer and inspect the body size:

const template = `
<b>Response body size (bytes):</b>
<ul>
<li>Body size: {{bodySize}}</li>
<li>Content size: {{contentSize}}</li>
<li>Compression: {{compression}}</li>
</ul>
`;

const bodySize = pm.response.text().length;
const contentSize = pm.response.size().body;
const compression = bodySize - contentSize; // bytes saved

pm.visualizer.set(template, { bodySize, contentSize, compression })

You have to select the Visualize tab in the Response pane, and it looks something like this:

[Albob]

@kevinswiber

const template = `
<b>Response body size (bytes):</b>
<ul>
<li>Body size: {{bodySize}}</li>
<li>Content size: {{contentSize}}</li>
<li>Compression: {{compression}}</li>
</ul>
`;

const bodySize = pm.response.text().length;
const contentSize = pm.response.size().body;
const compression = bodySize - contentSize; // bytes saved

pm.visualizer.set(template, { bodySize, contentSize, compression })

This actually gives me a negative compression:

This must be the difference between the raw text and the expanded/pretty JSON displayed. Or maybe you inverted body and content size ?

const contentSize = pm.response.text().length;
const bodySize = pm.response.size().body;

Anyway, this is miles away of the real compressed size that I can read from Chrome: ~25KB instead of ~146KB

[Albob]

And yeah +1 on this request 👍

[zhao1532072926]

+1

[kevinswiber]

@Albob There could be a number of reasons for this. My first guess would be that the Content-Length header isn't matching the actual length of the response body. This can happen when proxies, for example, modify the response body without modifying the value of the Content-Length header. The compression value should never be less than zero.

Why is Chrome showing different results? That's an interesting one. Check the Accept-Encoding request header in Postman and make sure it matches what you're seeing in Chrome. Then check the Content-Encoding response header in both Postman and Chrome to make sure they match.

[yevhenii-username]

+1

[joebone]

seriously? I have a chunked transfer encoded gzip stream with no content length at all, and not even via the dev tools is this available? Calls to the proxy, sure. And in the console, all of the response headers, but the actual like to the body? Body is more than 10 KB and can only be viewed in editor. Except the uncompressed version is 140 megs, and printing it "pretty" isn't great.

Bad form, Peter! [Hook reference for you younguns Guess its back to curl again.. and not the windows one, which apparently doesn't support --compressed

wsl curl --compressed -so /dev/null http://www.whatsmyip.org/http-compression-test/ -w '%{size_download}'

[wilbit]

+1

[Buyukcaglar]

Any updates on this feature?

[icedice]

I need this as well, annoying that we cannot see this out of the box.

[xiekeyi98]

+1, I need this to investigate server-side performance issues and compare different compression methods( gzip , br , deflate,etc)

[nastassia-citian]

Anyone have any alternatives for calculating compressed response size?

[icedice]

Anyone have any alternatives for calculating compressed response size?

I solved it by running the traffic through mitmproxy and checking the size there, it works but it's a bit convoluted for a basic task.

[Buyukcaglar]

Anyone have any alternatives for calculating compressed response size?

Insomnia

[bcmcq]

+1 🙏

[bjaraszk]

+1

[nastassia-citian]

I ended up adding middleware to my routes to log the compressed / decompressed size. Cross checking with dev tools network tab, it seems pretty accurate.

const logDataSize = (data) => {
    console.warn(`res object size ${typeof data === 'object' ? '(compressed)' : '(decompressed)'}: `, Buffer.byteLength(JSON.stringify(data), 'utf8') / 1024 / 1024 + ' MB');
};

// Middleware function to log response size
app.use((req, res, next) => {
    const originalSend = res.send;

    if (req.app.get('env') === 'development') {
        res.send = function(data) {
            logDataSize(data);
            originalSend.call(this, data);
        };
    }

    next();
});

[Greg-Hyliion]

+1

[TheAustinG]

Do +1s even matter at this point? This issue is going on 4 years with no updates. I doubt this is even close to being on their roadmap. Super disappointing.

Anyway, +1 in case it actually does carry any weight lol

[Quezler]

+1

[yuenhy]

+1

[tapionx]

+1

[itsdax]

✨ +1 ✨

[gfrancomsft]

+1

[cocorossello]

+1

[alexanderb444]

+1

[Nabeelaron]

Any updates on the feature request ? @shamasis

[PDonoso-DMF]

+1