postmanlabs / postman-app-support

Postman is an API platform for building and using APIs. Postman simplifies each step of the API lifecycle and streamlines collaboration so you can create better APIs—faster.
https://www.postman.com
5.84k stars 839 forks source link

cURL code snippet encodes + when Postman does not. #12478

Open ge-clicktools opened 12 months ago

ge-clicktools commented 12 months ago

Is there an existing issue for this?

Describe the Issue

When using a plus sign, "+", in a URL query part the cURL snippet will show the sign encoded at %2B on the request. This is inconsistent with Postman's behaviour, which sends plus signs as plus signs, and are then interpreted as spaces by the server.

Steps To Reproduce

  1. Open a new tab in Postman
  2. Use a GET url of https://postman-echo.com/get?foo=bar+baz
  3. Open the "Code" sidebar
  4. Choose cURL in the sidebar. It displays
    curl --location 'https://postman-echo.com/get?foo=bar%2Bbaz'
  5. Click Send. The response starts...
    {
    "args": {
        "foo": "bar baz"
    },
  6. In a command prompt run the curl command from step 4. The response starts...
    {
    "args": {
    "foo": "bar+baz"
    },

So Postman is showing a cURL command that does something different from Postman's own behaviour. Namely, the cURL command encodes "+" to "%2B" where Postman's Send button does not.

The behaviour is the same whether the request setting for "Encode URL automatically" is on or off.

I am using Postman on Windows and curl in WSL Ubuntu.

Screenshots or Videos

No response

Operating System

Windows

Postman Version

10.20.0

Postman Platform

Postman App

User Account Type

Signed In User

Additional Context?

This relates to issue https://github.com/postmanlabs/postman-app-support/issues/8626. It covers when Postman should or should not encode characters.

This issue is to make the code snippets be the equivalent of using the Send button, regardless of what encoding decisions Postman makes. I have used cURL as an example. Other snippet languages are also affected, perhaps all.

egjny commented 11 months ago

This is unlikely to be fixed, as the developers have steadfastly refused to acknowledge the HTTP RFCs as authoritative since at least 2020.