BMU-779: encode path params in typescript sdk for proper escaped URI

[kafis]

The path params inside of the URI are not escaped. This leads to URLs that are not valid.

Example: A customer of ours is using special characters in its product key: 123455[P]

The URL to update or retrieve the product by key is constructed then like https://api.europe-west1.gcp.commercetools.com/konrad-dev-002/products/key=518210[P]'

After the introduction of the change, the constructed url will look like this: https://api.europe-west1.gcp.commercetools.com/konrad-dev-002/products/key=1234%5BP%5D

[markus-azer]

im little bit doubtful here, cause thats not backward compatibility example user is already passing encoded uri, meaning 1234%5BP%5D will be 1234%255BP%255D.
maybe have major version change or at least pass it as optional cmd option while init the generator sth like --enable_encoding_uri

@jenschude wdyt?

[kafis]

There is a new clue. The sdk does escape blanks without further instructions 🔍

[kafis]

Ok, I investigated the behaviour of the underlying node-js fetch library.

The underlying node-js fetch library does utilize Request to parse and "clean" the passed url string. See here

It turns out, that

• the url will be urlencoded
• parts of the url, that are already encoded, will not be encoded again
• square brackets are unfortunately not dealt with

I created a little fiddle for the simulations. You can run it from the cmd line via node <file>

/**
 * This test evaluates the behaviour of nodeJs underlying fetch implementation.
 * It evaluates, whether it
 *  - automatically encodes URLs
 *  - Does not encode already encoded URLs
 */

const assert = require('assert')
function url(path) {
  return `http://api.com${path}`
}
function test(description, url, expected) {
  const request = new Request(url)
  assert(request.url === expected, `${request.url} !== ${url}`)
}

test(
  'Does encode by default',
  url('/space space'),
  url('/space%20space')
)
test(
  'Does not encode already encoded',
  url('/space%20space'),
  url('/space%20space')
)
test(
  'Does encode curly braces',
  url('/curly{braces}'),
  url('/curly%7Bbraces%7D')
)
test('Does not encode already encoded curly braces',
  url('/curly%7Bbraces%7D'),
  url('/curly%7Bbraces%7D')
)
test('Does not encode square brackets :(',
  url('/square[brackets]'),
  url('/square[brackets]'),
)
test(
  'Would not encode encoded square brackets',
  url('/square%5Bbrackets%5D'),
  url('/square%5Bbrackets%5D'),
)
test(
  'Does not double encode Markus example',
  url('/1234%5BP%5D'),
  url('/1234%5BP%5D'),
)

user is already passing encoded uri, meaning 1234%5BP%5D will be 1234%255BP%255D.

According to the executed simulation, this will fortunately not happen. Therefore I deem this change as being safe

[markus-azer]

That pretty good PR and findings 💯