postmanlabs
Show compressed body size
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
+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.
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.
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:
@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 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.
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}'
