escaping inconsistent

[srl295]

We ran into an issue https://github.com/IBM-Cloud/gp-js-client/issues/113 where a path component (part of a parameter) was for example a ' (A, space, quote). Going into the URL Interceptor so that we can add authorization the path was escaped to a URL such as http://example.com/api/a%20' - so far so good. But then, when the request was actually sent, the Fetch module ran the URL through url.parse again, resulting in http://example.com/api/a%20%27. This results in the same logical behavior, however, the exact URL string is different causing our HMAC calculation to be wrong.

I worked around this in https://github.com/IBM-Cloud/gp-js-client/pull/114/files#diff-38aee4b3886a621f8daddb4104803472R91 by having an interceptor run url.parse() on the URL pre-emptively before HMAC calculation, which makes the later parse a no-op.

I was a little surprised that quote (%27) gets escaped as it is acceptable per HTTP. Probably the larger issue is that the escaping that happens within swagger-js should match the escaping that actually goes out on the wire.

[srl295]

this was observed under 3.3.1 and also master (so 3.4.4+)

[shockey]

Thanks for the report, @srl295!

We've had this issue crop up in the past, looks like we might have a blind spot.

[srl295]

url.parse("http://example.com/'").href;
// --> http://example.com/%27

[shockey]

Hmm - I'm not able to reproduce this on my end:

What browser are you seeing this in? I'm on macOS Chrome 63.

[srl295]

@shockey this is via node.js API, not browser. And interesting, looking at your inspector… in this case though, the HTTP request isn't wrong, the problem is that what's passed to the interceptor is not what goes out over the wire. The Fetch module does another escaping after the interceptor is done.

I think i can make a standalone case for it.

[shockey]

Ah, got it. My hunch is that this is an implementation difference.

Looking forward to a demo for this (a failing test would be great!)

[webron]

@srl295 ping? :)

[srl295]

@webron pong ^

[srl295]

@shockey ping ^ ?

[shockey]

@srl295 pong! will look at this soon 😄

[char0n]

@srl295 thank you for reporting this and for providing a failing test.

The problem is in node-fetch library that we use when swagger-client is run in node.js runtime.

Actual url requested in node.js

fetch("http://localhost:8080/ '") -> url: /%20%27

Actual url requested in browser

fetch("http://localhost:8080/ '") -> url: /%20'

The actual problem lies in node-fetch implementation of fetch interface. The implementation is using legacy API instead of new WHATWG URL API. And that is causing inconsistencies. Fortunately [email protected] swichched to new WHATWG URL API. So the moment we switch to major version 3.x of node-fetch this issue will auto-correct.

I'm leaving this issue open untill we update node-fetch to 3.x branch. Before closing this issue #1252 needs to be incorporated into our tests to verify that the problem is gone.

[char0n]

Addressed in https://github.com/swagger-api/swagger-js/pull/3137/commits/f9207bd1d2663e87d10cdab7ff5b9aefe026c8fa, which is part of https://github.com/swagger-api/swagger-js/pull/3137.

Thank you for patience.

[srl295]

@char0n thanks!

[swagger-bot]

:tada: This issue has been resolved in version 3.21.0 :tada:

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot :package::rocket: