Fix: Don't pre-urlencode Postman collection query keys/values

[chengkangzai]

Summary

PostmanCollectionWriter::generateUrlObject() calls urlencode() on every query parameter key and value (and on URL parameter values) before writing them to the collection. Per the Postman Collection v2.1 schema, query[].key / query[].value and variable[].value are stored as raw strings — the Postman client encodes them when it assembles the outgoing HTTP request.

Pre-encoding here causes a double-encode on send. For example:

/**
 * @queryParam include string Example: customer,reward
 */

Generates this in collection.json:

{ "key": "include", "value": "customer%2Creward" }

When the user clicks Send, Postman encodes the value again → server receives ?include=customer%252Creward. Frameworks decode once → customer%2Creward, which strict request parsers (e.g. Spatie QueryBuilder, which splits includes on a literal ,) reject as a single unknown include.

URL parameter values had the same issue.

What changed

• query[].key, query[].value, variable[].value are now stored unencoded.
• The raw URL field still needs to be a syntactically valid URL, so rawurlencode() is applied only when assembling that string. (Switched to rawurlencode because urlencode encodes spaces as +, which is only valid in application/x-www-form-urlencoded bodies — not query strings per RFC 3986.)

Tests

• All 10 existing tests in PostmanCollectionWriterTest pass unchanged. They only used plain alphanumeric values (5, 34, foobar) where pre-encoding was a no-op, which is why this latent bug went unnoticed.
• Adds a regression test (query_parameter_keys_and_values_are_not_pre_url_encoded) covering comma + bracket + space cases, asserting:
  • query[] entries store raw values
  • variable[] entries store raw values
  • raw URL is encoded for HTTP validity

Related

• Closes Why do we url-encode query params when creating a postman collection? #877 (asks why query params are URL-encoded in the Postman collection — this is the answer: it shouldn't be).

Notes for reviewers

This is a behavioral change visible in generated Postman collections. Users who imported a previously-generated collection and observed %2C / %5B / %5D in the displayed key/value will now see literal , / [ / ]. Postman renders both forms identically when sending, so no user-facing regression — only the underlying double-encode bug is fixed.