Add Server header to Polaris API responses to indicate Polaris version #2941
Conversation
| public void filter( | ||
| ContainerRequestContext requestContext, ContainerResponseContext responseContext) { | ||
| if (headerEnabled) { | ||
| responseContext.getHeaders().putSingle(HttpHeaders.SERVER, SERVER_HEADER_VALUE); |
There was a problem hiding this comment.
I can use jakarta.ws.rs.core.HttpHeaders but I will have to define a custom SERVER header for the same. Let me know if I have to change it
|
Hi @fivetran-arunsuri Quarkus already exposes a similar feature: https://quarkus.io/guides/http-reference#additional-http-headers Couldn't you leverage that? For example: quarkus.http.header."Server".value=Polaris/${quarkus.application.version} |
|
The It will also allow downstream builds to control whether the version header is exposed or not with per-deployment granularity (which is sufficient IMHO). However, users of ASF Polaris binaries may not be able to "unset" the default value of this property 🤔 Those users will only be able to override it to something like |
|
Thanks @adutra @dimas-b — I verified the Quarkus option works:
I kept the ServerHeaderFilter behind polaris.http.version-header.enabled (default false) based on the previous dev email discussion to have a true off switch (fully removes the header, not just overrides). This addresses the “can’t unset” concern you mentioned. I’ll also document the Quarkus property as a downstream-friendly alternative for per-deployment control. Unless there are objections, I’ll merge this as-is and add docs:
If you’d rather we switch to config-only now, happy to do that, but I think this strikes a good balance (explicit toggle + simple override path). |
|
If we can avoid adding java code to support the new header, it would be preferable from my POV. @fivetran-arunsuri : could you check whether adding If that works, it should be sufficient. I do not expect suppressing this header to be a common use case and advanced uses can figure it out (provided we add comments in the default config). |
|
Thanks @dimas-b, confirmed that adding a non-matching path (/disabled) prevents the header from being added, while keeping .value defined avoids the config-validation error. simplified the PR to use the Quarkus http.header mechanism only, drop the custom filter, and document:
|
github-project-automation
bot
moved this from PRs In Progress
to Ready to merge
in Basic Kanban Board
I'd prefer this "no additional code" approach as well and document it. |
|
|
||
| # --- Polaris Server header (Quarkus-managed) --- | ||
| # Keep .value present (required by Quarkus), but make the path never match so it's effectively OFF by default. | ||
| quarkus.http.header."Server".value=Polaris/${quarkus.application.version} |
There was a problem hiding this comment.
Do we need to put anything in this file? The property is not marked as a build-time property in the configuration reference.
I think users could just add this setting in their own configuration. There should be no need to rebuild Polaris, just add it in one of the supported configuration sources.
There was a problem hiding this comment.
Good point. Doc changes alone should be sufficient for users.
There was a problem hiding this comment.
+1 on doc only, we don't have to make it default here. Thanks @adutra for the suggestion.
There was a problem hiding this comment.
Makes sense, thanks everyone for confirming. I’ll proceed with docs-only changes since users can add this configuration themselves.
5 participants
Fixes #2785
This change adds a Server response header to all HTTP responses, formatted as:
Server: Polaris/1.1
Details
PR to use the Quarkus http.header mechanism for enabling Polaris version
When enabled, the header will be included in all outgoing HTTP responses.
The primary purpose of this feature is observability — allowing clients or monitoring tools to identify the responding service version.
Testing:
Header inclusion when the flag is enabled.
Absence of the header when the flag is disable