Hi All, Re: the "X-" header notation... IIRC, the "X-" prefix is no longer required [1], right?
For observability purposes, I tend to think the good old Server header [2][3] might be sufficient. Introducing a new "Polaris-Version" header is more of a protocol concern. In that case, as discussed, capability flags are preferable, I believe. If the intention here is just to collect information about the server implementation, using a "Polaris-*" header in downstream projects may not be appropriate since "Polaris" is specifically the Apache Polaris project. [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers [2] https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Server [3] https://www.rfc-editor.org/rfc/rfc9110.html#name-server Cheers, Dmitri. On Wed, Oct 15, 2025 at 7:58 PM Yufei Gu <[email protected]> wrote: > > 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/> > > >
