Versions Compared

Old Version 34

changes.mady.by.user Jeff Huang

Saved on

compared with

New Version 35

changes.mady.by.user Jeff Huang

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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

private void configureHttpResponsHeaderFilter(ServletContextHandler context) 
  String headerConfig = workerConfig.getString(WorkerConfig.RESPONSE_HTTP_HEADERS_CONFIG);
  FilterHolder headerFilterHolder = new FilterHolder(HeaderFilter.class);
  headerFilterHolder.setName("default");
  headerFilterHolder.setInitParameter("headerConfig", headerConfig);
  context.addFilter(headerFilterHolder, "/*", EnumSet.of(DispatcherType.REQUEST));
}

...

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. 

...