Follow_redirects not implemented in http output plugin for Logstash

Elastic Stack Logstash
1

I am having difficult time making logstash http output plugin to forward events to http endpoint which returns 307. (no control over that). Redirect needs to be followed to get to the right URL.

Docs specify follow_redirects option:
https://www.elastic.co/guide/en/logstash/current/plugins-outputs-http.html#plugins-outputs-http-follow_redirects

Looking at the source code this seems to be not implemented at all.
Unless I'm looking in the wrong place:

Logstash just blows up whenever it sees 307

My logstash config:

input {
  beats {
       port => 5656
       host => "127.0.0.1"
  }
}

output {
  http {
	http_method => "post"
	format => "message"
	content_type => "application/json"
	url => "http://127.0.0.1:111/foo/bar"
	message => '%{message}'
	follow_redirects => true
	headers => {
		"foo" => "bar"
	}
  }
}

Is there a workaround? Is it planned to be implemented?

Thanks!

2

It looks like the follow_redirects option is passed to the HTTP client library, but there could of course be a bug somewhere.

3

I'm not a ruby dev, so it is hard for me to investigate, but I don't see how this option is passed to http client from Logstash http plugin. It seems only URL, method, body and headers are passed.

Or is it implicitly available via some scope ruby magic?

4

Unless I'm mistaken the class in the file I linked to is basically merged with the http output plugin class so everything in the mixin class is also available in the plugin.

5

Thanks Magnus, will try to debug with http mixin client.

7

The http library used is very conservative when it comes to status code handling. According to the RFC only HEAD and GET requests should be automatically redirected. Others like POST need user interaction (e.g. a browser dialog window).

The HTTP client does allow for having a custom redirect strategy to override this behaviour and even provides a more Lax strategy..aptly named LaxRedirectStrategy. Even this strategy won't redirect PUT requests, only HEAD/GET/DELETE/POST.

So at the moment there is no workaround other than using a GET request instead of a POST against the endpoint.