Encode plus sign in query parameters automatically

[GcfWarDelicacies]

Describe the bug failed to encode URL component

Screenshots all turn on

when I encode URL component manually, it's ok but when I do not, it's not ok

App information (please complete the following information):

• Native App

• version:

• OS: win 1909 18363.836

[codenirvana]

Looks like the query processor used in the requester server treats + as spaces. According to the URL Standards, + is a safe character and does not require mandatory percent-encoding.

This is similar to every other client and browsers. Are you expecting Postman to automatically encode + in query parameters?

[GcfWarDelicacies]

@codenirvana yes, I want postman to encode every param I try in chrome same problem

[codenirvana]

Considering this as a feature request. Note: Since this is non-standard, this feature will be enabled via a per-request setting.

[LuomingXu]

I think this feature will be very useful. Could it be added soon?

[sparta-developers]

our users use + sign in their emails, like myemail+something@gmail.com

we use Postman to reproduce login issues and see plus not URL encoded, which our server expects and treats + as a space.

[danbars]

When using the key/value UI, some characters are encoded (& and =), while others are not (+ and %). From a user experience perspective, I'd expect the UI to have consistent behavior - either I have to enter escaped strings, or the app encodes them for me. I think it should escape all characters that has to be escaped. If I want to manage my own escaping logic, I can use raw body and do whatever I want.

[sarthakverma14]

@codenirvana is this feature implemented?

[magnuswikhog]

If I activate Encode URL automatically and Use next generation URL processing, I expect parameters to come out on the server exactly as I entered them in Postman - including + characters.

Maybe it's just me, but it doesn't really make sense to me that some special characters (for example /) in a GET-parameter arrive intact on the server, but others (i.e. +) get mangled into spaces. Is this expected behaviour?

I'm using the Postman Desktop app, version 7.32.0 on Mac OSx.

[roosto]

I have just lost 3 or 4 hours to this bug.

If I turn on automatic encoding, I need Postman to ensure that my literal values will be sent to the server in a way that the server will be able decode them and read them as they were set. The fact that Postman does the right thing when injecting variable as values into headers, post params, and body payloads but then has different behavior when dealing with url params is very unexpected.

If I run a script that sets foo='100%', and then I make a request with /path?foo={{foo}} I get a 400 back from the server b/c of the illegal lone % in the query string. I feel like I should have to be trying a lot harder than this to coerce the software into sending malformed requests.

The whole reason to use a tool like Postman is to unburden yourself from the obnoxious little pieces like URL encoding and instead reason about the larger logic of how one’s API acts in complex multi-step chains.

[borsini]

I second this bug report. To let the user decide, having a checkbox to automatically encode all query params would be great.

[siggemannen]

This problem seems to persist in the newest version as well

[ghost]

The problem still occurs on postman v8.7.0

[cmbarnett87]

Still an issue in v9.0.2

[rysiuwroc]

Still an issue in v9.14.0

[sourabhgomebs]

Still an issue in v9.15.2

[pkernevez]

The '+' char is considered as a separator (ie a space). This is not valid when sending a date. A query parameter for a date (date=2021-04-08T19:32:01+02:00) is received as '2021-04-08T19:32:01 02:00' on the server and can't be parsed. Same discussion here: https://stackoverflow.com/questions/54294843/plus-sign-not-encoded-with-resttemplate-using-string-url-but-interpreted

[mhtmalpani]

A hack is to make use of the Pre-request Script in Postman.

Paste the following in the Pre-request Script section. This will transform all our params in the Request Url to be encoded. Thus all the + sign would be encoded to %2B

var querycount = pm.request.url.query.count();
for(let i = 0; i < querycount; i++) {
  pm.request.url.query.idx(i).value = encodeURIComponent(pm.request.url.query.idx(i).value);
}

[liautaud]

According to the URL Standards, + is a safe character and does not require mandatory percent-encoding.

Which exact standards are you referring to here?

According to section 8.2 of RFC1866, browsers looking to send form data in a GET request should add ? to the URI and then append the form data encoded using the form-urlencoded encoding from section 8.2.1. In that encoding, all space characters are replaced by +, and + characters are URL-encoded to %2B. Given that, the only way for a web server or framework to comply with this RFC is to assume that a + character in the query part of a URI refers to a space and not to the + character.

[RichardDight]

It's crazy that this is still an issue. Thanks @mhtmalpani for the snippet

[Littlecowherd]

var querycount = pm.request.url.query.count();
for(let i = 0; i < querycount; i++) {
  pm.request.url.query.idx(i).value = encodeURIComponent(pm.request.url.query.idx(i).value);
}

Thanks

[VCourdy]

A hack is to make use of the Pre-request Script in Postman.

Paste the following in the Pre-request Script section. This will transform all our params in the Request Url to be encoded. Thus all the + sign would be encoded to %2B

var querycount = pm.request.url.query.count();
for(let i = 0; i < querycount; i++) {
  pm.request.url.query.idx(i).value = encodeURIComponent(pm.request.url.query.idx(i).value);
}

Thanks !

You can also handle environment variables this way

var querycount = pm.request.url.query.count();
for(let i = 0; i < querycount; i++) {
    const value = pm.environment.replaceIn(pm.request.url.query.idx(i).value)
    pm.request.url.query.idx(i).value = encodeURIComponent(value);
}

[sh4dowb]

Looks like the query processor used in the requester server treats + as spaces. According to the URL Standards, + is a safe character and does not require mandatory percent-encoding.

This is similar to every other client and browsers. Are you expecting Postman to automatically encode + in query parameters?

where did you get these "url standards" from?

https://www.w3.org/Addressing/URL/uri-spec.html https://www.rfc-editor.org/rfc/rfc1630.txt Within the query string, the plus sign is reserved as shorthand notation for a space. Therefore, real plus signs must be encoded. This method was used to make query URIs easier to pass in systems which did not allow spaces.

https://developers.google.com/maps/url-encoding lists plus sign under Reserved

https://datatracker.ietf.org/doc/html/rfc3986#section-2.2 lists plus sign under reserved characters (sub-delims) which is used for delimiting stuff (if you're wondering, = is also on the same list. as far as I know postman encodes that.)

i'm pretty sure when I type a plus sign into a human input box, I mean it as a real plus sign. even regular javascript encodes it in the expected format.

why is this issue still open for years, and why are developers so insistent on pushing their own wrong ideas or knowledge, when these indisputably correct standards, specifications and rules defined years ago are used in like literally 100% of sane applications except postman?

I'm guessing it's a fix in postman-request/lib/url-parse.js in function charactersToPercentEncode, but what the hell do I know, apparently these developers have some wise knowledge not accessible by us mortals, that plus sign is a safe character when literally every resource and application tells otherwise.

[charlesverge]

Interesting to note that when you generate a curl request in postman desktop it produces the correct encoding for the plus sign.

[egjny]

This is a bug, and it has been known to be a bug. The developer @codenirvana has obviously never read the HTTP RFCs, and is persisting in some kind of absurd insistence that "+" is a "safe character". Depressing all around. Shades of Newtonsoft promiscuous date parsing in this insistence on preserving wrong behaviour.

[the1337beauty]

I've just encountered this issue when interacting with CrowdStrike APIs.

[SomeBdyElse]

@codenirvana , @giridharvc7 Could this please be addressed?