Add Server header to Polaris API responses to indicate Polaris version

[fivetran-arunsuri]

Description:

Currently, Polaris API responses do not include a Server header. For example, when performing a POST /api/catalog request, the response headers include only:

Content-Type: application/json;charset=UTF-8
content-encoding: gzip
content-length: 187

There is no header identifying the Polaris server or its version.

Enhancement Proposal:
Add a standard Server header in all HTTP responses from Polaris services.
For example:

Server: Polaris/1.1.0

Rationale:

• Provides better observability and diagnostics during development and debugging.
• Allows users and clients to easily verify the server version they’re communicating with, especially across multi-environment or multi-region deployments.
• Simplifies support and compatibility checks when interacting with different Polaris API versions.
• Aligns with common REST API practices — many Apache and commercial services include Server or custom headers (e.g., X-Server-Version) for version traceability.

Optional Consideration:
If exposing the server version publicly is a concern for security reasons, a custom header like:

X-Polaris-Version: 1.1.0, could be used instead.

[dimas-b]

@fivetran-arunsuri : could you provide specific examples of Apache projects that provide server or version headers in their REST API responses (just for reference)?

[dimas-b]

From my POV observability and compatibility checks are very different use cases. The server/version header does make sense for observability, but I believe it might be preferable to use a different mechanism for compatibility checks. The latter is often not as simple as checking version >= X, so using capability flags may be more maintainable.

[fivetran-arunsuri]

Thanks, @dimas-b. agreed, capability flags would indeed be more robust for compatibility management.

Our primary use case is observability and very basic validation. We’d like the Polaris server to include a version identifier in the standard Server header (e.g., Server: Polaris/1.1.0). On the client side, we plan to send an X-Expected-Server header to validate that the response comes from the intended Polaris deployment or version.

[fivetran-arunsuri]

@fivetran-arunsuri : could you provide specific examples of Apache projects that provide server or version headers in their REST API responses (just for reference)?

I guess many Apache projects, especially those that either function as servers or are built on top of web servers, do expose these headers by default. AFAIK Apache Tomcat exposes something like: Server: Apache-Coyote/1.1

[dimas-b]

Tomcat, of course 😉 I thought you meant something that is not a generic web container, but a service with a REST API 🙂

[dimas-b]

Exposing a header like Server: Polaris/1.1.0 sounds good to me as long as there is a way to suppress it with configuration (since it might, indeed, be considered a sensitive piece of data in some environments).

I'd also recommend starting a dev email discussion on this for visibility.

[fivetran-arunsuri]

Thanks, @dimas-b, that’s a good point regarding configurability.

We can definitely make the Server header optional and controllable via a config flag (e.g., polaris.server.header.enabled=false) to address environments where version disclosure is restricted.

I’ll start a thread on the dev mailing list to gather broader feedback on the header format and default behavior. Appreciate the inputs!

[fpapon]

May be adding a property to be able to set the header name can be useful in case of the api is expose behind an api-gateway or a http proxy that already define the same header?