Detect old Kibana UI on serverless server

[jloleysens]

Since our thinking has evolved on the original issue here are my thoughts on technical details of an approach to just detecting old browsers/UIs on Kibana server.

On serverless we will be deploying versions "between" stack versions but we only communicate the stack version today (i.e. 8.9.0) via the kbn-version header.

Proposal for detecting old UIs

We modify the version being sent via kbn-version to something that can represent a new Kibana build (as opposed to just a new stack version). Top of my head I can imagine two approaches:

1. We update the kbn-version value with a build number: something like 8.9.0+123abcdefg and keep it SemVer compliant.
2. Change kbn-version to something entirely new like a build hash 123abcdefg, non SemVer compliant

I prefer (1), I also think it will be easier to implement as it remains largely compatible with how this value is used today, but I can also see a case for (2) in that "stack version" is not really a thing on serverless anymore.

Note: we have a way to get a unique build number for Kibana, this will be a number like 64910 not an actual commit SHA. In development we just set this to Node.js' max int. See:

https://github.com/elastic/kibana/blob/a39531edce1c59e18c1f5b77e62cf77ac5e43ef2/src/dev/build/lib/get_build_number.ts

Open to other ideas of course!

[elasticmachine]

Pinging @elastic/kibana-core (Team:Core)

[pgayvallet]

Between the two listed options, I'd rather go with 1 too. The upsides I see is that we still know about the stack version, and call still properly infer the build number from the semver string, without any downsides I can think of.

I can also see a case for (2) in that "stack version" is not really a thing on serverless anymore

Yeah, but I don't think it matters much in the end. That header is an "internal" header that in theory is only used for kibana UI<->server communication, so it's value and format can probably be considered an implementation detail ihmo.

Note that an alternative would be to keep kbn-version and add the buildNum (or any value that could be used as a "serverless version") in a new, dedicated header, but I think it just introduces more complexity without any significant upsides, so I don't think that would be better in any way compared to the {semver}-{buildNum} approach.

[lukeelmers]

Note that an alternative would to keep kbn-version and add the buildNum (or any value that could be used as a "serverless version") in a new, dedicated header,

I was going to suggest this as well. We now have the build hash included in the status API (in both serverless and self-managed iirc), so I could see a kbn-build-hash header making sense. But considering {version}+{buildNum} is still valid semver I think option 1 is fine too, so no strong feelings on this.

[rayafratkina]

Related to #163671