Fixed SendHttpClientRequest to accept '&' in both username and password

[kevinamorim]

I found a bug when using JWT authentication. If the username or password has an ampersand (&) character the request body params get messed up.

Converting all ampersands characters to their UTF-8 hex representation fixed the problem.

The original data is never altered.

PS: I also closed the data stream after writing to it and added the ContentLength header to the request.

[pricerc]

There are a couple of standard methods that will handle this without requiring a custom method:

https://docs.microsoft.com/en-us/dotnet/api/system.web.httputility.urlencode
https://docs.microsoft.com/en-us/dotnet/api/system.net.webutility.urlencode

while you spotted a problem with ampersands, there may be other characters that also cause trouble. Spaces, slashes, greater-than and less-than spring to mind as possible candidates.

I recently ran into a similar problem on a completely unrelated project.

In that same project, I also had a problem with Unicode characters messing with the ContentLength, because the size returned by Encoding.UTF8.GetBytes() is not necessarily the correct ContentLength.. (I can't remember if ContentLength was more or less, but it was different). The solution was to just not specify the ContentLength and let the underlying library handle it.

[kevinamorim]

There are a couple of standard methods that will handle this without requiring a custom method:

https://docs.microsoft.com/en-us/dotnet/api/system.web.httputility.urlencode
https://docs.microsoft.com/en-us/dotnet/api/system.net.webutility.urlencode

while you spotted a problem with ampersands, there may be other characters that also cause trouble. Spaces, slashes, greater-than and less-than spring to mind as possible candidates.

I recently ran into a similar problem on a completely unrelated project.

In that same project, I also had a problem with Unicode characters messing with the ContentLength, because the size returned by Encoding.UTF8.GetBytes() is not necessarily the correct ContentLength.. (I can't remember if ContentLength was more or less, but it was different). The solution was to just not specify the ContentLength and let the underlying library handle it.

Thanks! I should use UrlEncode() then.
I'll try to fix this!