Plugin API - Response headers are not transient

Elastic Stack Elasticsearch
1

From my Elasticsearch plugin, I want to set HTTP response headers. What I do is:

threadPool.getThreadContext().addResponseHeader("header1","value1");

And this works, but when another request comes along, Elasticsearch will still carry "header1" as a response header. In other words, I expected the response headers to be transient, i.e. to be reset for every request.

Or at least, I expected to be able to be able clear/remove/overwrite them, but this is not possible as for current API.

// Throws Method threw 'java.lang.UnsupportedOperationException' exception.
threadPool.getThreadContext().getResponseHeaders().clear();

Please advise, am I doing this wrong?

2

Can you show more of what your plugin is doing? In which thread are you trying to modify the thread context? What plugin apis is your plugin extending?

3

all this went back to normal when I made sure the response headers were set from a thread in the original ES thread pool. Setting them from a completable future of an async HTTP client request caused problems.

Also, to make it work with 6.7.0 I had to wrap all my code in a:

try (ThreadContext.StoredContext ctx = threadPool.getThreadContext().stashContext()) {
  ... all my code that uses HTTP client and set response headers...
}

The above was necessary because the deprecation logger set a response header with a null value and threw a NullPointerException.

[2019-03-29T13:10:53,149][WARN ][r.suppressed             ] [d-qW6Ay] path: /_template/metricbeat-6.7.0, params: {name=metricbeat-6.7.0}
java.lang.NullPointerException: value
	at io.netty.util.internal.ObjectUtil.checkNotNull(ObjectUtil.java:33) ~[?:?]
	at io.netty.handler.codec.DefaultHeaders.addObject(DefaultHeaders.java:327) ~[?:?]
	at io.netty.handler.codec.http.DefaultHttpHeaders.add(DefaultHttpHeaders.java:117) ~[?:?]
	at org.elasticsearch.http.netty4.Netty4HttpChannel.setHeaderField(Netty4HttpChannel.java:168) ~[?:?]
	at org.elasticsearch.http.netty4.Netty4HttpChannel.setHeaderField(Netty4HttpChannel.java:163) ~[?:?]
	at org.elasticsearch.http.netty4.Netty4HttpChannel.addCustomHeaders(Netty4HttpChannel.java:189) ~[?:?]
	at org.elasticsearch.http.netty4.Netty4HttpChannel.sendResponse(Netty4HttpChannel.java:113) ~[?:?]
	at org.elasticsearch.rest.RestController$ResourceHandlingHttpChannel.sendResponse(RestController.java:497) ~[elasticsearch-6.7.0.jar:6.7.0]
	at org.elasticsearch.rest.action.RestResponseListener.processResponse(RestResponseListener.java:37) ~[elasticsearch-6.7.0.jar:6.7.0]
	at org.elasticsearch.rest.action.RestActionListener.onResponse(RestActionListener.java:47) [elasticsearch-6.7.0.jar:6.7.0]
	at org.elasticsearch.action.support.TransportAction$1.onResponse(TransportAction.java:85) [elasticsearch-6.7.0.jar:6.7.0]
	at org.elasticsearch.action.support.TransportAction$1.onResponse(TransportAction.java:81) [elasticsearch-6.7.0.jar:6.7.0]
4

Can you share more details about this please?

5

@jasontedor the issue was described by a user of trying to make the code work with ES 6.7.0

Which was fixed with this commit:

6

Okay, thanks for clarifying. The way that I read this is that it is not a problem in Elasticsearch server. Please correct me if I have it wrong.

7

The main issue seems the extra null value in a certain response header which is not set by the plugin.

{Warning=[299 Elasticsearch-6.7.0-8453f77 "[types removal] The parameter include_type_name should be explicitly specified in put template requests to prepare for 7.0. In 7.0 include_type_name will default to 'false', and requests are expected to omit the type name in mapping definitions.",  null]

Apparently the extra null is present only when the plugin is installed. Stashing the thread context removes the header entirely, but it does not look like a solution to the root cause.

Did we forget to implement some interface method?

8

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.