KuttSharp
KuttSharp copied to clipboard
avestura
Replace FormUrlEncodedContent with StringContent
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.
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?
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:
@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?
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.