Hi all, Thank you for the suggestions in the previous discussion. I’ve raised a PR for the same, please review when you get a chance: 👉 https://github.com/apache/polaris/pull/2941
On Fri, Oct 17, 2025 at 11:13 PM Yufei Gu <[email protected]> wrote: > The Server version header should be treated as informational only. Clients > must not rely on it for compatibility checks, that purpose is handled by > the config endpoint. > > We can reuse the standard Server header[1], which supports extensions such > as: > Server: Quarkus xxx Polaris/1.0 > > 1. https://www.rfc-editor.org/rfc/rfc9110.html#name-server > > > > Yufei > > > On Fri, Oct 17, 2025 at 7:22 AM Dmitri Bourlatchkov <[email protected]> > wrote: > > > 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] > > .invalid> > > > 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/> > > > > > > > > > > -- 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/>
