You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@polaris.apache.org by Arun Suri <ar...@fivetran.com.INVALID> on 2025/10/15 13:38:45 UTC
[DISCUSS] Proposal: Add Server Header in Polaris API Responses
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
arun.suri@fivetran.com
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/>
Re: [DISCUSS] Proposal: Add Server Header in Polaris API Responses
Posted by Robert Stupp <sn...@snazy.de>.
Hi all,
Alex mentioned an interesting alternative to just use a Quarkus
configuration option for this. [1]
That option feels much easier and more flexible to me than adding code.
I'd personally let my services not expose any software version
information, because it's pretty neat functionality to find vulnerable
services.
Robert
[1] https://github.com/apache/polaris/pull/2941#issuecomment-3468684311
On Thu, Oct 30, 2025 at 4:12 AM Arun Suri
<ar...@fivetran.com.invalid> wrote:
>
> 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 <fl...@gmail.com> 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 <di...@apache.org>
> > 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 <fl...@gmail.com> 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 <arun.suri@fivetran.com
> > > .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
> > > > > arun.suri@fivetran.com
> > > > > 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
> arun.suri@fivetran.com
> 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/>
Re: [DISCUSS] Proposal: Add Server Header in Polaris API Responses
Posted by Arun Suri <ar...@fivetran.com.INVALID>.
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 <fl...@gmail.com> 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 <di...@apache.org>
> 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 <fl...@gmail.com> 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 <arun.suri@fivetran.com
> > .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
> > > > arun.suri@fivetran.com
> > > > 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
arun.suri@fivetran.com
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/>
Re: [DISCUSS] Proposal: Add Server Header in Polaris API Responses
Posted by Yufei Gu <fl...@gmail.com>.
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 <di...@apache.org>
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 <fl...@gmail.com> 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 <arun.suri@fivetran.com
> .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
> > > arun.suri@fivetran.com
> > > 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/>
> > >
> >
>
Re: [DISCUSS] Proposal: Add Server Header in Polaris API Responses
Posted by Dmitri Bourlatchkov <di...@apache.org>.
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 <fl...@gmail.com> 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 <ar...@fivetran.com.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
> > arun.suri@fivetran.com
> > 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/>
> >
>
Re: [DISCUSS] Proposal: Add Server Header in Polaris API Responses
Posted by Yufei Gu <fl...@gmail.com>.
> 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 <ar...@fivetran.com.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
> arun.suri@fivetran.com
> 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/>
>