Allow custom HTTP responses and message to be set in the config file

[vinnyw]

Thanks for contributing to Logstash! If you haven't already signed our CLA, here's a handy link: https://www.elastic.co/contributor-agreement/
This can be very useful if the input plugin is running behind a proxy or application firewall service.

[gmatheu]

Any plans to accept this PR?

We have an scenario were our log messages are sent using SOAP. In order to make it transparent to the message sender, we have to answer a valid SOAP Envelope (a static message is acceptable).

[b0ch3nski]

+1

I think that this PR could partially fix Logstash issue RFE: Accept native logs from systemd-journal-upload.

[jordansissel]

@b0ch3nski Copying my comment from logstash#2594

I checked the HTTP RFC -- https://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html

It seems like the web server the http input uses needs to support this kind of upload style where the client sets Expect: 100-continue. According to the RFC, the server still needs to respond with a final status code, so it is my conclusion that adding a custom response code will not solve the systemd-upload problem.

[jordansissel]

@vinnyw I don't yet understand what problem this PR solves. Can you help me? For example, in what scenario would you want to set change 200 to something else? Or when would you leave it as 200 but change the status message?

[vinnyw]

Changing of the status code would be useful in the situation where you have logs coming in though a proxy process, or something that is acting as a validation/security filter (such as Mod_security or more specifically something like Naxsi). Having the ability of settings the response code to a non-200 response, allows the proxy process to take the validated response and perform a custom action on it. A lot of proxy processes will not allow you to override the action of a default 200 response internally and will stop the chain of processing.

The request flow would follow something similar to:

request -> non-200 response -> internal handler in proxy -> hand off to logstach, and give 200 respose back.

Setting of the message, was added as an optional extra and was there just for completeness of configuration and flexibility. The main feature was to be able to change the response code to allow processing routing within the proxy process.

[rbkasat]

can this be merged, I think this has a lot of use cases..

[jsvd]

@rbkasat can you talk about the use case for you?
The core code has changed a bit so the implementation needs to be redone. so I'd like to know which if these options are useful for you.

From @vinnyw 's usecase there's a need to change the default 200 response on an successful request. And for you?

[rbkasat]

I also need the default to be changed to 204 so I can use this as a proxy and clients expect 204
But I think that's not the only thing,
I want this to support 100-Continue so not sure how this will fit in usecase. And wondering if its possible to send different status codes depending on different uri's

[jsvd]

It seems the best enhancement for these requests would be a complete routes capability a la sinatra to specify different routes that return custom bodies and response codes.

Another separate enhancement is to support "Expect: 100-continue", which is tracked in #86.

In the meantime it seems the smallest necessary change to solve both use cases presented here is to customize the response code on success, with a parameter like config :response_code, :default => 200, :validate => :integer.

[jsvd]

closing since the plugin code has deviated and rewritten with netty so this patch isn't applicable any more