prism: Postman plus Prism Proxy causes errors

Describe the bug I use Postman (https://www.postman.com/) with Prism, with good results. When I put Prism into proxy mode, Postman thinks it didn’t get a response (but curl to the same endpoint works fine).

Prism shows no error messages, the output from Prism is identical whether I make the request through Postman or curl

Postman’s console says “incorrect header check”

curl shows that Prism is returning a header content-encoding: gzip, which I don’t get when I request the live API directly rather than via the Prism proxy.

To Reproduce

Given this OpenAPI document (actually I’m not sure it matters but I’m using https://github.com/Nexmo/api-specification/blob/master/definitions/verify.yml and hitting the search/ endpoint
Run this CLI command prism proxy verify.yml https://api.nexmo.com/verify
Make a request to the Search endpoint using Postman

Expected behavior The API response

Environment (remove any that are not applicable):

Library version: 3.2.9
OS: Ubuntu 18.04
Postman 7.21.1
curl: 7.58.0

Additional context I managed to get things working by adding an additional header to Postman Accept-Encoding and leaving it empty - I think Postman sends this header by default. However curl does not send Accept-Encoding by default and I still see that Prism returns a content-encoding: gzip to curl so while I’m not sure Postman is sending correct headers, I think Prism is also adding something here that doesn’t help!

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 24 (12 by maintainers)

Most upvoted comments

I am facing this issue too. Prism 4.1.2, node.js both 12.19.1 and 14.15.1.

It is clearly not specific to Postman. From my observation, the issue can be generalised as this:

Client send request to Prism proxy with Accept-Encoding: gzip header
Proxy forwards the request to upstream server with that header
Upstream returns gzipped (binary) body with Content-Encoding: gzip header
Proxy forwards it back to client, keeping the Content-Encoding: gzip header BUT with un-gzipped (decoded) body
Client is confused because it got content marked as gzipped, but in fact, it is already decoded

Solution would be either not to decode the body and return it intact, or (as hotfix) strip the Content-Encoding header

ondrakoupil on Apr 22, 2021

@hilary Thanks for the detailed explanation! With these new details I’ll reopen the issue and try to reproduce!

XVincentX on Jun 30, 2020

Thanks @lornajane, your workaround is working for us, too.

Hi @XVincentX. We’re also having the same problem. To reproduce, run

prism proxy ...

not

prism mock ...

The problem we’re encountering is with Postman (and newman) through prism running as a validation proxy. We also encountered the same problem using httpie with prism proxy.

As best we can tell, the problem is happening because:

a client is adding a default) Accept-Encoding: gzip, deflate header to requests
the response isn’t, in fact, encoded/gzipped (the spec does not specify it as such and the live API doesn’t return gzipped responses)
prism proxy is trying to gunzip the response for some reason (as part of validation?), despite it not being in the spec/contract

When the header is not sent by the client, everything works fine.

Whether the header is sent by the client or not should not affect the behavior of the validation proxy, given that the spec does not specify that the response is encoded.

hilary on Jun 30, 2020

@arunvangapelli That hasn’t been released yet in the 3.x branch; you need to either install the beta tag or clone the master branch directly.

I’ll try to publish this in the 3.x on Monday or so.

XVincentX on Aug 23, 2020