Page History

...

We should provide a mechanism to return the desired headers. We can't, in general, anticipate what specific headers their scanners will demand now, much less in the future, so we must make this mechanism configurable.  Also we don't foresee the requirement to set different headers for different paths or mime types (since these Connect API servers only return application/json).

...

Since we're using Jetty to serve this, we can take advantage of the Jetty HeaderFilter class to allow the configuration of these headers. We add configuration property response.http.headers.config in the org.apache.kafka.connect.runtime.WorkerConfig class and update org.apache.kafka.connect.runtime.rest.RestServer class. During initialization process,  Connect REST server will read all header configurations from the property response.http.headers.config, and create a FilterHolder with HeaderFilter class and add the filter holder to the Servlet context handler. We only need to provide a single HeaderFilter for the entire server, because that HeaderFilter can set as many headers as the customer needs. Both set and add action will add a header and value to the response header if the header is not already in the response. When the header is there, set action overwrites the existing value, whereas add action adds an additional value to the header value. So it is the Kafka user's applications and server administrator responsibility to manage headers configured and existing headers. 

...