added option 'ignorable_codes' to also return failed REST calls

[rpasche]

Setting this option to true will return the response headers and response body also for failed REST calls. This means, unless there is an exception, setting ignore_errors to true will always succeed.

The idea behind is to also be able to fetch the results for failed HTTP requests, parse them and - maybe - use that data within elasticsearch.

[cla-checker-service]

💚 CLA has been signed

[MikeKemmerer]

Any chance you can roll in the "form" change I made, too? They haven't been too quick on accepting pull requests for this plugin.

[kares]

Nice addition, however I think a better approach would be to make the 200-299 "valid" response codes configurable.
Accepting intervals as well as individual response code (in an array), wdyt?

[rpasche]

Hmm... Yes. Need to think about it. So you mean that you need to give the codes of "valid" codes in an array of this option is set to true.

[kares]

I mean not having ignore_errors but having a valid_responses => ... option instead (anything else is an error).
The idea would be to somehow support ranges => ['200-299', 302] as well as individual response codes => [200, 201, 204], given that LS does not support ranges this might need more work.

Not yet sure what the best approach would be to represent ranges, hopefully some other plugin is using smt similar already.

[rpasche]

@kares Found a bit time to further work on this. For now, I'm just doing exactly the same as the ignorable_codes (https://www.elastic.co/guide/en/logstash/current/plugins-outputs-http.html#plugins-outputs-http-ignorable_codes) within the logstash http output plugin. That should make it a bit more consistent.

[rpasche]

I am not able to run bundle exec spec anymore. I get some dependency error when I try this within my WSL. So hoping, that all tests pass...