1. Updated KIP adding prefix response.http.headers.{name}.
2. Updated KIP using a table to describe type and validate values.
3. Added meaningful examples for Connect scenarios.
4. We use comma to separate different HTTP headers. But we do allow the header
value contain comma, just need use double
Thanks for the proposal, Jeff. I can see how this proposal will add value.
I have a few comments, most of which are asking for more detail in the KIP.
1. I do think the KIP needs to be much more explicit about what the new
configuration properties will be and to use them consistently. For e
Hi Aneel,
It is great idea. I will update KIP based on your suggestion.
Jeff.
On 2020/03/13 18:58:23, Aneel Nazareth wrote:
> If we're including and excluding paths, it seems like it might make
> sense to allow for the configuration of multiple filters.
>
> We could do this with a pattern si
If we're including and excluding paths, it seems like it might make
sense to allow for the configuration of multiple filters.
We could do this with a pattern similar to how Kafka listeners are
configured. Something like:
response.http.header.filters = myfilter1,myfilter2
response.http.header.myfi
Hi Aneel,
That is really great point. I will update KIP. We need add following properties
combining with header configs:
includedPaths - CSV of path specs to include
excludedPaths - CSV of path specs to exclude
includedMimeTypes - CSV of mime types to include
excludedMimeTypes - CSV of mime types
Hi Jeff,
Thanks for the KIP.
Will users always want to set identical headers on all responses? Does
it make sense to also allow configuration of the HeaderFilter init
parameters like "includedPaths", "excludedHttpMethods", etc.? Does it
make sense to allow multiple configurations (so that eg. dif
