Status

Current state:  Under Accepted

Discussion thread: here

Discussion Vote thread: here

JIRA: here

Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).

...

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. 

The following is flow how this will be implemented in RestServer class: 

• REST application load loads configuration file 
• Application parse parses the property response.http.headers.config in configuration file using RestConfig if application based on rest-utils or using WorkerConfig if application is Kafka Connectsing WorkerConfig
• creates Application create FilterHolder with HeadFilter class.  Application ServletContextHandler add the 
• HeadFilteradds the FilterHolder into ServletContextHandler

Pseudocode

...

Supporting multiple header filters add complexity to configuration properties and cause site administrator confusions on configuring Connect REST serverServer.  Most important thing is we do not see applicable customer scenarios at this time. One header filter is sufficient for all HTTP response headers based on existing customer application scenarios and concern.  We could expand existing implementation easily if customer need it in the future.  For instance, we could add multiple header filters by adding name of header filter between prefix response.http.headers and config such as response.http.headers.{name}.config. We still keep response.http.headers.config as default header filter and internally set name of header filter to default if there is nothing between the response.http.headers and config. 

...