> Simplifies support and compatibility checks when interacting with different Polaris API versions.
This is currently taken care by the IRC config endpoint, which sends the server capability back to clients, https://github.com/polaris-catalog/polaris/blob/main/spec/iceberg-rest-catalog-open-api.yaml#L1941-L1941. And we could add more specific properties if needed. Does it meet your use cases? With that, I agreed that having a server version(like X-Polaris-Version) could benefit observability and debuggability. Also agreed with Dmitri to have a flag to toggle it. Yufei On Wed, Oct 15, 2025 at 6:39 AM Arun Suri <[email protected]> wrote: > Hi all, > > Continuing the discussion from here on github issue > <https://github.com/apache/polaris/issues/2785> > > During recent development and debugging sessions, we noticed that Polaris > API responses currently do not include any server identification headers. > For example, a typical response to a POST /api/catalog request contains: > > Content-Type: application/json;charset=UTF-8content-encoding: > gzipcontent-length: 187 > > There’s no header indicating the Polaris service or version that handled > the request. > *Proposal* > > Add a standard HTTP header in all Polaris service API responses, such as: > > Server: Polaris/1.1.0 > > *Rationale* > > - > > *Improved observability and diagnostics:* Helps identify which Polaris > deployment handled a request, especially across regional or environment > boundaries. > - > > *Simplified validation:* Enables clients to verify they’re communicating > with the expected Polaris instance or version (we plan to use a matching > X-Expected-Server header on the client side). > - > > *Industry alignment:* Common practice across Apache projects — for > example, Apache Tomcat exposes Server: Apache-Coyote/1.1. > > *Optional Configurability* > > To address security or compliance considerations, this feature could be > controlled via feature flag: > > polaris.server.header.enabled=false > > By default, it could remain* disabled.* > Thanks to Dmitri for earlier inputs suggesting configurability and > distinguishing observability from compatibility management. > > Looking forward to your thoughts on this. > > -- > Arun Suri > > Senior Software Engineer > > He/him/his > > Engineering | Fivetran > [email protected] > fivetran.com <//fivetran.com> > <http://www.fivetran.com> > [image: facebook] <https://www.facebook.com/Fivetran/> [image: twitter] > < > https://twitter.com/fivetran?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor > > > [image: > linkedin] <https://www.linkedin.com/company/fivetran> [image: instagram] > <https://www.instagram.com/fivetran_ig/> >
