Nothing has been registered, nothing to use for encoding/decoding

[rtorino]

I tried out the stringsvc example. After I generated the middlewares and run it and execute curl -XGET -d'{"str":"test"}' localhost:12345/stringservice/uppercase I get Nothing has been registered, nothing to use for encoding/decoding error.

[Ayiga]

Greetings rtorino,

The reason this issue occurs is because go-kit-middlewarer supports multiple methods of Encoding and Decoding requests and responses. The service is informed by the HTTP Header information, in the form of Content-Type and Accept headers. In this case you should be specifying an encoding type, and sending the appropriately encoding request.

Please note that even empty requests may need to be encoded, though I plan on working on this and modifying it.

If you simply modify your curl request by adding a Content-Type header and a data payload you should get a response:

curl -XGET -d'{"str":"test"}' -H 'Content-Type: application/json' localhost:12345/stringservice/uppercase

In the mean time, I'll look into not requiring a body, and Content-type for methods that don't have arguments.

Thanks for the information.

[rtorino]

@Ayiga Thanks. I also figured it out. But it would be nice if the Content-Type header is optional and maybe set the default to Content-Type: application/json if it's not complicated to implement. I appreciate your time to look into my issue, actually it's not really an issue. Good job :+1:

[Ayiga]

@rtorino I've just uploaded some changes to add content type sniffing, and brute force detection fall-backs. This should help detect which mime is being used, so you aren't explicitly required to specify the Content-Header.

That being said, the behavior was already to use a default encoding that was set to application/json. However, the behavior of the curl utility is interesting in that it tries to be very well behaved about the Header's it supplies. By default it sets to application/x-www-form-urlencoded. You can see this when you output the verbose mode: curl -v -s localhost:9000/stringservice/count -d '{"str":"test"}'

This is why it was returning that error. However, that being said, that error was the wrong error to return in that situation. The correct error should have been "That mime type does not have an associated Encoder/Decoder". I've updated this in the code, so that's a plus.

Now. The new process for the Default Encoding Handler goes something like this:

• Attempt to Determine Mime based on content headers supplied (Content-Type, and Accept specifically).
• If nothing can be determined, fall back on the Default Encoding in the case of Encoding information, in the case of Decoding we will fall back to Sniffing.
• If nothing was determined, successfully, based on sniffing, cycle through the remaining registered encodings that have not been attempted.

This chain will tend to resolve the mime type identification automatically. The brute force method could potentially have some potentially drastic impacts on memory usage and performance. This sniffing method should be a better in terms of performance. However, there will still be increased memory usage, and there do exist the potential for false positives, which can slow down the performance.

The best solution is to supply the Content-Type and Accept whenever possible. Using the binary clients generated will take care of this for you automatically. However, when you're just testing and you want to deliver a request with curl or something, the sniffing and brute-force methods should go a long way toward debugging and being helpful.

Please let me know if you have any questions, if you find any more issues, or if you have any more recommendations,

Thanks,

~ Ayiga

[rtorino]

:+1: