Replace FormUrlEncodedContent with StringContent

[bojidar-danchev]

I have found a bug in the Kutt API which results in 'false' or 'False' to be considered a true (truthy) value. I'm working on a fix for that but it leads me to think that x-www-form-urlencoded is not the intended way for using the API, so I've made this simple change to use a Newtonsoft serialized JSON as string content instead.

[avestura]

I have found a bug in the Kutt API which results in 'false' or 'False' to be considered a true (truthy) value.

What is this bug you're facing?

[bojidar-danchev]

I have found a bug in the Kutt API which results in 'false' or 'False' to be considered a true (truthy) value.

What is this bug you're facing?

Basically - this:

You can see that a request made with 'false' as a URL encoded parameter returns "reuse": true in the response. Hitting the endpoint twice returns the same shortened URL. This works the same way using the C# library and the v2 API.

There is also a secondary issue which happens only with URL encoded calls - the Redis caching of the API actually returns the same single shortened URL even if you call the API with a different target:

I made the same request with a different target but the first URL was returned. This is the bigger issue that I want to debug but I haven't been able to properly configure and run the Kutt API in debug mode yet.

You can see in the API source code at line 57 how the reuse which causes a value like 'false' to be considered true, the same with any other non empty string.
Removing the reuse from the request:

makes it work as expected.
The same goes for sending a raw body:

[avestura]

@poeti8 Can you take a look at the above message? It seems x-www-form-urlencoded is not a standard way to talk with the API. Should we take care of this in the client, or it's better to be solved in the server?

[bojidar-danchev]

I've created this pull request for the API which should solve the issues on that side and enable the usage of x-www-form-urlencoded input. I still feel like this should not be the preferred way to use the API as it is likely to cause more issues in the future.